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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



IP Multimedia (IM) Core Network (CN) subsystem Service Continuity (SC) provides the capability of continuing 
ongoing communication sessions with multiple media across different access networks or across different user 
equipments (UEs) under the control of the same subscriber. 

The present document provides the protocol details for enabling IMS SC based on the Session Initiation protocol (SIP) 
and the Session Description Protocol (SDP) and the protocols of the 3GPP Circuit-Switched (CS) domain (e.g. CAP, 
MAP, ISUP, BICC and the NAS call control protocol for the CS access). 

The present document is appUcable to User Equipment (UEs) and Application Servers (AS) providing IMS Service 
Continuity capabilities. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) 

and Session Description Protocol (SDP); Stage 3". 

[3] 3GPP TS 24.228 Release 5: "Signalling flows for the IP multimedia call control based on Session 

Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3". 

[4] 3GPP TS 24.292: "IP Multimedia (IM) Core Network (CN) subsystem Centralized Services (ICS); 

Stage 3". 

[5] 3GPP TS 24.216: "Communication continuity managed object". 

[6] 3GPP TS 29.328: "IP Multimedia Subsystem (IMS) Sh interface; SignalUng flows and message 

contents". 

[7] 3GPP TS 29.329: "Sh interface based on the Diameter protocol; Protocol details". 

[8] 3GPP TS 24.008: "Mobile radio interface layer 3 specification; Core Network protocols; Stage 3". 

[9] 3GPP TS 23.237: "IP Multimedia subsystem (IMS) Service Continuity; Stage 2". 

[10] IETF RFC 3891: "The Session Initiation Protocol (SIP) "Replaces" Header". 

[II] IETF RFC 4538: "Request Authorization through Dialog Identification in the Session Initiation 
Protocol (SIP)". 

[12] 3GPP TS 23.003: "Numbering, addressing and identification". 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP 
3GPP TR 21.905 [1]. 

CS call: A connection established via the circuit switched domain in accordance with the related procedures e.g. such 
as described in 3GPP TS 24.008 [8] and of which the established bearer is only used within a CS connection but not 
used as a media stream for a related IM CN subsystem session. 

CS media: A connection established via the circuit switched domain in accordance with the procedures in 

3GPP TS 24.008 [8] of which the established bearer is used a media stream for a related IM CN subsystem session, i.e. 

the CS media is established due to prior or parallel IM CN subsystem SIP and SDP signalling. 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.237 [9] apply: 

Access Leg 

Remote Leg 

Target Access Leg 

Source Access Leg 

Session Transfer Identifier (STI) 

Session Transfer Number (STN) 

Session Transfer Number for SR-VCC (STN-SR) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.003 [12] apply: 
IP Multimedia Routing Number (IMRN) 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPPTR 21.905 [1]. 

IMRN IP Multimedia Routing Number 

SC Service Continuity 

sec Service Centralization and Continuity 

SR-VCC Single Radio VCC 

STI Session Transfer Identifier 

STN Session Transfer Number 

4 Overview of IP IVIultimedia (IIVI) Core Network (CN) 

subsystem Service Continuity 

4.1 General 

In general, IMS Service Continuity provides the capability of continuing ongoing communication sessions with multiple 
media across different access networks or across different user equipments (UEs) under the control of the same 
subscriber. The main need for such continuity arises because (i) UEs with multimedia capabilities can move across a 
multiplicity of different access networks or because (ii) the users can move the media of their communication sessions 
across different UEs to best meet their communication preferences. 

The following procedures are provided within this document: 

procedures for registration in IM CN subsystem are specified in clause 6; 
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procedures for call origination are specified in clause 7; 

procedures for call termination are specified in clause 8; 

procedures for PS-CS session continuity are specified in clause 9; 

procedures for PS-PS session continuity are specified in clause 10; 

procedures for PS-PS session continuity in conjunction with PS-CS session continuity are specified in clause 11; 

procedures for PS-CS session continuity for Single Radio are specified in clause 12; and 

procedures for media adding/deleting in clause 13. 

For a UE or an AS not supporting ICS procedures, PS-CS service continuity is only possible when the UE is active in a 
single full-duplex speech or speech/video session i.e. support of session transfer with more than one sessions or with 
non voice media is not provided. 

4.2 Underlying network capabilities 

SC assumes the use of a number of underlying network capabilities: 

1) provision by the home network operator of SCC AS on the IM CN subsystem, as specified in 

3GPPTS 24.229 [2]; 

2) if ICS is used, the network capabilities as specified in 3GPP TS 24.292 [4]; 

4.3 URI and address assignments 

In order to support SC to a subscriber, the following URI and address assignments are assumed: 

a) in this version of the document, the SC UE will be configured with both a static STI and a static STN. The static 
STI is used by the SC UE to perform CS to PS session transfer when no dynamically assigned STI is provided to 
the UE over the CS domain (e.g. when the SC UE does not support ICS capabilities). The static STN is used by 
the SC UE to perform PS to CS session transfer when no service control signalling path as specified in 

3GPP TS 24.292 [4] is available. 

b) the SC UE will be configured to be reachable in both the IM CN subsystem and the CS domain by one or more 
public telecommunication numbers which should be correlated between the CS domain and IM CN subsystem. 
Either: 

this public telecommunication number can be the DN (e.g. MSISDN) used in the CS domain and (in 
international form) comprise part of the implicit registration set associated with that SC UE in the IM CN 
subsystem; or 

the SCC AS can be configured to provide a functional relationship between separate numbers providing each 
of these identities in the CS domain and the IM CN subsystem, respectively. 

5 Functional entities 



5.1 Introduction 



This clause associates the functional entities with the SC roles described in the stage 2 architecture document (see 
3GPP TS 23.237 [9]). 



5.2 User Equipment (UE) 



To be compliant with this document, a UE shall implement the role of a SC UE (see subclause 6.2, subclause 7.2, 
subclause 8.2, subclause 9.2, subclause 10.2, subclause 11.2 and subclause 12.2). 
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5.3 Application Server (AS) 

To be compliant with this document, a AS shall implement the role of a SCC AS (see subclause 6.3, subclause 7.3, 
subclause 8.3, subclause 9.3, subclause 10.3, subclause 11.3 and subclause 12.3). 

6 Roles for registration in the IM CN subsystem 

6.1 Introduction 

A 3rd-party registration shall be performed via the ISC interface for the SCC AS. 

6.2 SC UE 

The SC UE shall follow the procedures specified in 3GPP TS 24.229 [2] for registration of the UE in the IM CN 

subsystem. 

Prior to making use of IMS ICS procedures, the UE shall follow the procedures specified in subclause 6.2 in 
3GPP TS 24.292 [4] for registration of the ICS UE in the IM CN subsystem. 

6.3 SCC AS 

The SCC AS can be configured with any of various options for obtaining information from the IM CN subsystem 
specified in 3GPP TS 24.229 [2], 3GPP TS 29.328 [6] and 3GPP TS 29.329 [7], for example: 

a) receipt of REGISTER request from a third-party REGISTER request which is sent to the SCC AS; 

b) receipt of REGISTER request from a third-party REGISTER request which is sent to the SCC AS. The SCC AS 
then subscribes to the reg event package for that user to obtain information; or 

c) receipt of REGISTER request from a third-party REGISTER request which is sent to the SCC AS. The SCC AS 
then uses the Sh interface to obtain information. 

This document places no requirement on the use of all or any of these mechanisms. 



Roles for call origination 



7.1 Introduction 

This clause specifies the procedures for call origination, both where the SC UE is generating calls in the CS domain and 
where the SC UE is generating calls using the IM CN subsystem. Procedures are specified for the SC UE and the SCC 
AS.7.2SC UE 

The SC UE shall support origination of multimedia sessions in the IM CN subsystem as specified in 
3GPPTS 24.229 [2]. 

The SCC UE shall support origination of calls in the CS domain as specified in 3GPP TS 24.008 [8]. 

The procedures for call origination where the SC UE is initiating calls using CS media are identical to that for ICS UE 
which is specified in clause 7 in 3GPP TS 24.292 [4]. 



£75/ 



3GPP TS 24.237 version 8.0.0 Release 8 1 1 ETSI TS 1 24 237 V8.0.0 (2009-01 ) 

7.3 sec AS 

7.3.1 Distinction of requests sent to tine SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to call origination: 

SIP INVITE requests routed to the SCC AS over the ISC interface as a result of processing filter criteria at the S- 
CSCF according to the origination procedures as specified in 3GPP TS 24.229 [2], and therefore distinguished 
by the URI relating to this particular filter criteria appearing in the topmost entry in the Route header. In the 
procedures below, such requests are known as "SIP INVITE requests due to originating filter criteria". It is 
assumed that the SCC AS is the first AS that the S-CSCF forwards the request to after receiving the request from 
the UE. 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [8]. 

7.3.2 Call origination procedures at the SCC AS 

When the SCC AS receives a SIP INVITE request due to originating filter criteria, the SCC AS shall follow the 
procedures specified in 3GPP TS 24.292 [4] subclause 7.4. 



8 Roles for call termination 

8.1 Introduction 

This clause specifies the procedures for call termination, both where the SC UE is receiving calls in the CS domain and 
where the SC UE is receiving calls using the IM CN subsystem. Procedures are specified for the SC UE and the SCC 
AS. 

8.2 SC UE 

The SC UE shall support termination of multimedia sessions in the IM CN subsystem as specified in 

3GPPTS 24.229 [2]. 

The SC UE shall support termination of calls in the CS domain as specified in 3GPP TS 24.008 [8]. 

The procedures for call termination where the SC UE is receiving calls using CS media are identical to that for ICS UE 
which is specified in clause 8 in 3GPP TS 24.292 [4]. 

8.3 SCC AS 

8.3.1 Distinction of requests sent to the SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to call termination: 

SIP INVITE requests routed to the SCC AS over the ISC interface as a result of processing filter criteria at the S- 
CSCF according to the termination procedures as specified in 3GPP TS 24.229 [2], and therefore distinguished 
by the URI relating to this particular filter criteria appearing in the topmost entry in the Route header. In the 
procedures below, such requests are known as "SIP INVITE requests due to terminating filter criteria". It is 
assumed that the SCC AS is the last AS that the S-CSCF forwards the request to. 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 
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8.3.2 Call termination procedures in the SCC AS 

When the SCC AS receives a SIP INVITE request due to terminating filter criteria, the SCC AS shall follow the 
procedures specified in 3GPP TS 24.292 [4] subclause 8.4. 



9 Roles for PS-CS session continuity 

9.1 Introduction 

For a UE or an AS not supporting ICS procedures, PS-CS service continuity is only possible when the UE is active in a 
single full-duplex speech or speech/video session i.e. support of session transfer with more than one sessions or with 
non voice media is not provided. 

9.2 SC UE 

9.2.1 SC UE procedures for PS to CS session continuity 

The SC UE may be engaged in one or more ongoing IMS sessions at the time of initiating session continuity. By an 
ongoing IMS session, it is meant a session for which the 2xx response for the initial SIP INVITE request to establish 
this session has been sent or received. 

If the SC UE is using Gm, then for each session to be transferred and starting with the active session, the SC UE shall 
send a SIP INVITE request to the SCC AS as specified in 3GPP TS 24.292 [4] subclause 7.2.2. The SC UE shall 
populate the SIP INVITE request as specified for PS-PS session continuity with full media transfer in subclause 10.2.1. 

If the SC UE is not using ICS capabilities, then session continuity is only possible when the UE is active in a single full- 
duplex speech session. If multiple full-duplex speech sessions exist, the SC UE shall first initiate the release of all the 
ongoing full-duplex speech sessions that are currently not active. When transferring the active session, the SC UE shall 
send, to the SCC AS, a message (e.g. CC_SETUP as specified in 3GPP TS 24.008 [8]) to set up a call over the CS 
domain. When sending CC_SETUP, the SC UE shall populate the CC_SETUP as follows: 

1) the called party BCD number information element set to the static STN. 

If the SC UE receives a release message to the CC SETUP message sent, then PS-CS session continuity has not 
completed successfully and the call will continue in the Source Access Leg. 

9.2.2 SC UE procedures for CS to PS session continuity 

The SC UE may be engaged in one or more ongoing sessions before performing session continuity. By an ongoing 
session, it is meant a CS call for which the CS call setup procedure is complete, e.g. CC CONNECT message has been 
sent or received as described in 3GPP TS 24.008 [8] or a call for which the 2xx response for the initial SIP INVITE 
request to establish this session has been sent or received. 

If not already IMS registered, the SC UE shall follow the procedures specified in subclause 6.1 to perform IMS 
registration over the Target Access Leg before performing CS to PS session continuity. 

If the original sessions are established using ICS capabilities, then for each session to be transferred and starting with 
the active session, the SC UE shall send a SIP INVITE request to the SCC AS in accordance with 3GPP TS 24.229 [2] 
subclause 5.1. The SC UE shall populate the SIP INVITE request as specified for PS-PS session continuity with full 
media transfer in subclause 10.2.1. 

If the original sessions are not established using ICS capabilities, then session continuity is only possible when the SC 
UE is active in a single full-duplex speech session. If multiple full-duplex speech sessions exist, the SC UE shall first 
initiate the release of all the ongoing sessions that are currently not active. When transferring the active session, the SC 
UE shall send a SIP INVITE request to the SCC AS in accordance with 3GPP TS 24.229 [2] subclause 5.1. The SC UE 
shall populate the SIP INVITE request as specified for PS-PS session continuity with full media transfer in 
subclause 10.2.1 with the following differences: 
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1) the Request-URI set to the tel URI of the static STL 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request, then session transfer has not occurred 
and the call will continue in the CS domain. 

When the SC UE receives a CS call release message, e.g. CC DISCONNECT message as specified in 
3GPP TS 24.008 [8], from the network, the SC UE shall comply with network initiated call release procedures to 
release the CS bearer. When CC_DISCONNECT message is received, the SC UE shall comply with the network 
initiated call release procedures as specified in 3GPP TS 24.008 [8]. 

9.3 sec AS 

9.3.1 Distinction of requests sent to tine SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to access transfer: 

SIP INVITE requests routed to the SCC AS containing a STI belonging to the subscribed user in the Replaces 
header field or Target-Dialog header field. In the procedures below, such requests are known as "SIP INVITE 

requests due to STI ". 

SIP INVITE requests routed to the SCC AS containing a static STI in the Request-URI. In the procedures 
below, such requests are known as "SIP INVITE requests due to static STI". 

SIP INVITE requests routed to the SCC AS containing either a static STN or an IMRN in the Request-URI. In 
the procedures below, such requests are known as "SIP INVITE requests due to static STN ". 

NOTE: The media streams that need to be transferred are identified using information described in the subsequent 
sections. 

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 

9.3.2 SCC AS procedures for PS to CS session continuity 

When the SCC AS receives a SIP INVITE request due to STI on the Target Access Leg, the SCC AS shall follow the 
procedures specified in subclause 10.3.2. 

When the SCC AS receives SIP INVITE request due to static STN, the SCC AS shall associate the SIP INVITE request 
with an ongoing SIP dialog based on information associated with the received IMRN or based on information from the 
SIP History Info header field and P-Asserted header field and send a SIP re-INVITE request towards the remote user 
using the existing established dialog. By an ongoing SIP dialog, it is meant a dialog for which a SIP 2xx response to the 
initial SIP INVITE request has been sent or received. Multiple dialogs associated with the same SCC UE may have 
been anchored when the SCC AS receives a SIP INVITE request due to static STN. This can occur in the event that the 
UE does not succeed in releasing all inactive dialogs, in which case the identification of the associated dialog is subject 
to the following conditions: 

if only one SIP dialog exists for the user identified in the P-Asserted-Identity header field and a SIP 2xx response 
has been sent and there is active audio media, then continue the session transfer; 

if no SIP dialogs exist for the user identified in the P-Asserted-Identity header field where there is active audio 
media and a SIP 2xx response has been sent, then send a SIP 480 (Temporarily Unavailable) response to reject 
the SIP INVITE request relating to the session transfer; 

if more than one SIP dialog exists for the user identified in the P-Asserted-Identity header field and exactly one 
dialog exists where there is active audio media and a SIP 2xx response has been sent for that dialog, then: 

if the remaining dialogs have inactive audio media, then the SCC AS may release the inactive dialogs and 
continue the session transfer procedures; or 

if the SCC AS is not able to identify one dialog for session transfer, then the SCC AS shall send a SIP 480 
(Temporarily Unavailable) response to reject the SIP INVITE request relating to the session transfer. 
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Continuing the session transfer procedures, the SCC AS shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog with 
the remote user; and 

2) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to static STN, 
by following the rules of the 3GPP TS 24.229 [2]. 

Upon receiving the SIP ACK request from the IM CN subsystem, the SCC AS shall initiate release of the source access 
leg by sending a SIP BYE request toward the S-CSCF for sending to the served SCC UE. 

9.3.3 SCC AS procedures for CS to PS session continuity 

When the SCC AS receives a SIP INVITE request due to STI on the Target Access Leg, the SCC AS shall follow the 
procedures specified in subclause 10.3.2. 

When the SCC AS receives a SIP INVITE request due to static STI, the SCC AS shall associate the SIP INVITE 
request with an ongoing SIP dialog. By an ongoing SIP dialog, it is meant a dialog for which a SIP 2xx response to the 
initial SIP INVITE request has been sent or received. Multiple dialogs associated with the same SCC UE may have 
been anchored when the SCC AS receives a SIP INVITE request due to static STI. This can occur in the event that the 
UE does not succeed in releasing all inactive dialogs, in which case the identification of the associated dialog is subject 
to the following conditions: 

if only one SIP dialog exists for the user identified in the P-Asserted-Identity header field and a 2xx response has 
been sent and there is active audio media, then continue the session transfer procedures; 

if no SIP dialogs exist for the user identified in the P-Asserted-Identity header field where there is active audio 
media and a SIP 2xx response has been sent, then send a SIP 480 (Temporarily Unavailable) response to reject 
the SIP INVITE request relating to the session transfer; 

if more than one SIP dialog exists for the user identified in the P-Asserted-Identity header field and exactly one 
dialog exists where there is active audio media and a SIP 2xx response has been sent for that dialog, then: 

if the remaining dialogs have inactive audio media, then the SCC AS may release the inactive dialogs and 
continue the session transfer procedures; or 

if the SCC AS is not able to identify one dialog for session transfer, then the SCC AS shall send a SIP 480 
(Temporarily Unavailable) response to reject the SIP INVITE request relating to the session transfer. 

Continuing the session transfer procedures, the SCC AS sends a SIP re-INVITE request towards the remote user using 
the existing established dialog. The SCC AS shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog with 
the remote user; and 

2) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to the static STI, 
by following the rules of the 3GPP TS 24.229 [2]. 

Upon receiving the SIP ACK request from the IM CN Subsystem, the SCC AS shall initiate release of the source access 
leg by sending a SIP BYE request over the source access leg. 

If, subsequent to initiating the SIP re-INVITE request to the remote user, and prior to the SIP ACK request being 
received from the IM CN subsystem for the source access leg, the SCC AS decides (for any reason) to reject the session 
transfer request back to the UE (e.g. by sending a 4xx response), the SCC AS shall release the target access leg and 
maintain the source access leg. 
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1 Roles for PS-PS session continuity 

10.1 Introduction 

This clause specifies the procedures for PS-PS session continuity for both full media transfer case and partial media 
transfer case. Procedures are specified for the SC UE and the SCC AS. 

10.2 SCUE 

The SC UE may be engaged in one or more ongoing sessions before performing session continuity. By an ongoing 
session, it is meant a session for which the SIP 2xx response for the initial SIP INVITE request to establish this session 
has been sent or received. 

The SC UE may receive the operator policy via OMA Device Management, see 3GPP TS 24.216 [5]. When the SC UE 
receives the operator policy, for each session to be transferred, it shall take the operator policy into account when 
deciding to perform the following: 

- selecting the access for initiating the PS-PS transfer; 

- determining whether to transfer full or partial media during PS-PS transfer; or 

- determining whether to add or remove media during the PS-PS transfer. 

The SC UE shall follow the procedures specified in subclause 6.1 to perform IMS registration over the Target Access 
Leg before performing PS-PS session continuity. 

1 0.2.1 Full session transfer 

To initiate PS-PS session continuity for a session, the SC UE shall send a SIP INVITE request over the Target Access 
Leg in accordance with 3GPP TS 24.229 [2] subclause 5.1. The SC UE shall populate the SIP INVITE request as 
follows: 

1 . the Request-URI set to the URI contained in the Contact header field returned at the creation of the dialog over 
the Source Access Leg; 

2. select one of the following options: 

A. if usage of SIP Replaces extension is selected: 

a. the Replaces header field populated as specified in IETF RFC 3891 [10], containing the dialog identifier 
of the session to be transferred; and 

b. the Require header field populated with the option tag value "replaces"; 

B. if usage of SIP Target-Dialog extension is selected: 

a. the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog 
identifier of the session to be transferred; and 

b. the Require header field populated with the option tag value "tdialog"; and 

3. the SDP payload set for the media component(s) to be transferred, in accordance with subclause 6.1.1 and 
subclause 6. 1 .2 of 3GPP TS 24.229 [2]. The SDP shall contain the same number of media lines, each 
corresponding to one of the media components in the original session, unless media components need to be 
added. Each media line shall indicate the same media type as its corresponding media component in the original 
session and shall contain at least one codec that was negotiated during the original session. 

A) If the SC UE determines to remove a media component during the transfer, then the media line for this 
media component shall include a port number with value zero; and 
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B) If the SC UE determines to add new media component(s) during the transfer, then one additional media 
Hne with the desired media type and codecs shall be added for each new media component at the end of 
the SDP. 

Upon receiving SIP 2xx response for the SIP INVITE request sent over the Target Access Leg and sending SIP ACK 
request, if the dialog over the Source Access Leg is still active, the SC UE shall send a SIP BYE request to the SCC AS 
over the Source Access Leg to terminate the original session. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request sent over the Target Access Leg, then PS- 
PS session continuity has not completed successfully and the call will continue in the Source Access Leg. 

1 0.2.2 Partial session transfer 

To initiate PS-PS session continuity for a session, the SC UE shall send a SIP INVITE request over the Target Access 
Leg in accordance with 3GPP TS 24.229 [2] subclause 5.L The SC UE shall populate the SIP INVITE request as 
follows: 

the Request-URI set to the URI contained in the Contact header field returned at the creation of the dialog over 
the Source Access Leg; 

the Require header with the option tag 'tdialog' included; 

the Target-Dialog header populated as specified in IETF RFC 4538 [11], containing the dialog identifier of the 
session to be transferred; and 

the SDP payload set for the media component(s) to be transferred, in accordance with subclause 6. L 1 and 
subclause 6.1.2 of 3GPP TS 24.229 [2]. The SDP shall contain the same number of media lines in the same 
order, each corresponding to one of the media components in the original session, unless media components 
need to be added during the session transfer. Each media line shall indicate the same media type as its 
corresponding media component in the original session and shall contain at least one codec that was negotiated 
during the original session. 

1) If the SC UE determines to keep the media component on the Source Access Leg, then the media line for 

this media component shall include a port number with value zero; and 

2) If the SC UE determines to add new media component(s) during the transfer, then one additional media 

line with the desired media type and codecs shall be added for each new media component at the end of 
the SDP. 

Upon receiving SIP 2xx response for the SIP INVITE request sent over the Target Access Leg and sending SIP ACK 
request, the SC UE shall send a SIP re-INVITE request to the SCC AS over the Source Access Leg to update the 
original session. The SC UE shall populate the SIP re-INVITE request as follows: 

the SDP payload set for all the media component(s) within the original session, in accordance with 

subclause 6.1.1 and subclause 6. 1 .2 of 3GPP TS 24.229 [2] . The port number for a media component shall be set 

to zero if that media component has been transferred to the Target Access Leg or has to be removed. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request sent over the Target Access Leg, then PS- 
PS session continuity has not completed successfully and the call will continue in the Source Access Leg. 

10.3 SCC AS 

1 0.3.1 Distinction of requests sent to tine SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to access transfer: 

SIP INVITE requests routed to the SCC AS containing a STI belonging to the subscribed user in the Replaces 
header or Target-Dialog header. In the procedures below such requests are known as "SIP INVITE requests due 
to STI ". 
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NOTE: The media streams that need to be transferred are identified using information described in the subsequent 
sections. 

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 

1 0.3.2 PS to PS Session Continuity Procedures at tine SCC AS 

When the SCC AS receives a SIP INVITE request on the Target Access Leg due to STI, the SCC AS shall: 

associate the SIP INVITE received on the Target Access Leg with an ongoing SIP dialog i.e. identify the 
Source Access Leg. The Source Access Leg is identified by matching the dialog ID present in the Replaces (see 
IETF RFC 3891 [10]) or Target Dialog header (see IETF RFC 4538 [11]) of the SIP INVITE with an ongoing 
dialog. By an ongoing SIP dialog, it is meant a dialog for which a SIP 2xx response to the initial SIP INVITE 
request has been sent or received; 

if the SCC AS is unable to associate the SIP INVITE with a unique ongoing dialog, send a SIP 480 
(Temporarily Unavailable) response to reject the SIP INVITE request relating to the access transfer and not 
processes the remaining steps; 

if the SIP INVITE request contains a Replaces header: 

a) follow the procedures defined in IETF RFC 3891 [10] for replacing the Source Access Leg with the SIP 
request received on the Target Access Leg, including terminating the Source Access Leg by sending a SIP 
BYE towards the SC UE in accordance with 3GPP TS 24.229 [8]; and 

b) send a SIP re-INVITE request towards the remote user using the existing established dialog. The SCC AS 
shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog 
with the remote user; and 

2) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to STI 
received on the Target Access Leg, by following the rules of the 3GPP TS 24.229 [2]. 

otherwise, if the SIP INVITE request contains a Target Dialog header: 

a) if the number of media lines in the Target Access Leg is less than the number of media lines in the Source 
Access Leg or the media type for the corresponding media lines is not the same as in the original session, 
send a SIP 4xx response to reject the SIP INVITE request relating to the access transfer and not process the 
remaining steps; 

b) otherwise, send a SIP re-INVITE request towards the remote user using the existing established dialog. The 
SCC AS shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog 
with the remote user; and 

2) include a new SDP offer, following the rules specified in 3GPP TS 24.229 [2], containing the following 
media information: 

the media characteristics as received in the SIP INVITE request due to STI received on the Target 
Access Leg for media streams whose port is not set to zero; and 

for the media streams in the SIP INVITE request due to STI whose port is set to zero, include the 
corresponding media characteristics of those streams from the Source Access Leg, 

c) after receiving the SIP ACK request from the SC UE on the Target Access Leg, upon receiving an update 
(e.g. SIP re-INVITE) from the SC UE on the Source Access Leg, process the update request in accordance 
with 3GPPTS 24.229 [2]. 

If, subsequent to initiating the SIP re-INVITE request to the remote user, and prior to the SIP ACK request being 
received on the Target Access Leg, the SCC AS decides (for any reason) to reject the access transfer request (e.g. by 
sending a 4xx response), the SCC AS shall release the Target Access Leg, retain the Source Access Leg, and update the 
remote leg to match the Source Access Leg. 
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1 1 Roles for PS-PS session continuity in conjunction 
with PS-CS session continuity 

11.1 Introduction 

This clause specifies the procedures for PS-PS session continuity in conjunction with PS-CS session continuity. 
Procedures are specified for the SC UE and the SCC AS. For SC UE or SCC AS not supporting ICS procedures, PS-PS 
session continuity with a remote end in conjunction with PS-CS session continuity with the same remote end is only 
possible when the UE is active in a single CS session with full-duplex speech with the remote end i.e. support of session 
transfer with more than one session containing full-duplex speech component is not provided. 

11.2 SCUE 

11 .2.1 SC UE procedures for PS to PS+CS session continuity 

11.2.1.1 General 

The SC UE may be engaged in one or more ongoing IMS sessions before performing session continuity. By an ongoing 
session, it is meant a session for which the SIP 2xx response for the initial SIP INVITE request to establish this session 
has been sent or received. 

1 1 .2.1 .2 SC UE procedures for PS to PS-i-CS session continuity using ICS 

If the SC UE is using Gm, then for each session to be transferred and starting with the session with active full-duplex 
speech component, the SC UE shall send a SIP INVITE request to the SCC AS as specified for call origination using 
Gm in 3GPP TS 24.292 [4] subclause 7.2.2. The SC UE shall populate the SIP INVITE request as specified for PS-PS 
session continuity with full media transfer in subclause 10.2.1. The SC UE shall indicate in the SIP INVITE request that 
the speech media is using CS bearer. When sending the SIP INVITE request for the sessions with inactive full-duplex 
speech component and if precondition is used, the SC UE shall indicate that the related local preconditions for the 
speech component are met. 

For the session with active full-duplex speech component, upon receiving the PSI DN from the SCC AS, the SC UE 
shall follow the procedures for call origination using Gm in 3GPP TS 24.292 [4] subclause 7.2.2 to set up the CS bearer. 

1 1 .2.1 .3 SO UE procedures for PS to PS-i-CS session continuity not using ICS 

If the SC UE is not using ICS capabilities, then session continuity is only possible when the UE is active in a single 
session with full-duplex speech media component. For the non-speech components to be transferred to the PS Target 
Access Leg, the SC UE shall send a SIP INVITE request to the SCC AS as specified for PS-PS session continuity with 
partial media transfer in subclause 10.2.1. For the speech component to be transferred to the CS Target Access leg, the 
SC UE shall send to the SCC AS a CS call setup message, e.g., CC_SETUP as specified in 3GPP TS 24.008 [8]. When 
sending the CC_SETUP, the SC UE shall populate the CC_SETUP as follows: 

1) the called party BCD number information element set to the STN. 

Upon receiving the SIP 2xx response from the SCC AS for the PS Target Access Leg and sending SIP ACK request and 
upon receiving CS call setup confirmation message, e.g. CC_CONNECT message, for the CS Target Access Leg, the 
SC UE shall send a SIP BYE request to terminate the Source Access Leg, following the procedures specified in 
3GPPTS 24.229 [2]. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request for the PS Target Access leg and receives 
CS call setup failure message for the CS Target Access Leg, then session transfer has not occurred and the call will 
continue in the original domains. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request for the PS Target Access Leg and 
receives CS call setup confirmation message for the CS Target Access Leg, then the session transfer is only successful 
for part of the media components. The SC UE shall update the Source Access leg by following the procedures specified 
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for PS-PS session continuity with partial media transfer in subclause 10.2.2 to indicate that all media components other 
than the speech component are still maintained on the Source Access Leg. 

If the SC UE receives CS call setup failure message for the CS Target Access Leg but receives a SIP 2xx response for 
the PS Target Access Leg, then the session transfer is only successful for part of the media components. Upon sending 
SIP ACK request, the SC UE shall update the Source Access leg by following the procedures specified for PS-PS 
session continuity with partial media transfer in subclause 10.2.2 to indicate that the speech component is still 
maintained on the Source Access Leg. 

1 1 .2.2 SC UE procedures for PS+CS to PS session continuity 

11.2.2.1 General 

The SC UE may be engaged in one or more ongoing sessions before performing session continuity. By an ongoing 
session, it is meant a CS call for which the CC CONNECT message has been sent or received or a call for which the 
SIP 2xx response for the initial SIP INVITE request to establish this session has been sent or received. 

If not already registered over the PS Target Access Leg, the SC UE shall follow the procedures specified in 
subclause 6. 1 to perform IM CN subsystem registration over the Target Access Leg before performing PS/CS to PS 
session continuity. 

1 1 .2.2.2 SC UE procedures for PS+CS to PS session continuity using ICS 

If the original sessions are established using ICS capabilities, then for each session to be transferred and starting with 
the session with active full-duplex speech media component, the SC UE shall send a SIP INVITE request to the SCC 
AS in accordance with 3GPP TS 24.229 [2] subclause 5.1. The SC UE shall populate the SIP INVITE request as 
specified for PS-PS session continuity with full media transfer in subclause 10.2.1. The SC UE shall indicate in the SIP 
INVITE request that the speech media component is using PS media. 

Upon receiving SIP BYE request for the Source Access Leg, the SC UE shall follow the ICS using Gm procedures 
specified in 3GPP TS 24.292 [4] to release the session. The SC UE also releases the associated CS bearer if no other 
sessions depend on the CS bearer. 

1 1 .2.2.3 SC UE procedures for PS-i-CS to PS session continuity not using ICS 

If the original sessions are not established using ICS capabilities, then session continuity is only possible when the SC 
UE has a single session with active full-duplex speech media component. The SC UE shall send a SIP INVITE request 
to the SCC AS in accordance with 3GPP TS 24.229 [2] subclause 5.1. 

The SC UE shall populate the SIP INVITE request as follows: 

- the Request-URI set to static STI; 

the Require header field including "replaces" option tag; 

the Replaces header field populated as specified in IETF RFC 3891 [10], containing the dialog identifier of the 
session to be transferred on the PS Source Access Leg; and 

the SDP payload set for the media component(s) to be transferred, in accordance with subclause 6.1.1 and 
subclause 6.1.2 of 3GPP TS 24.229 [2]. The SDP shall contain media components in the following order: 

1) One speech media component to be transferred; 

2) The same number of media lines, each corresponding to one of the media components in the session on the 
PS Source Access Leg; Each media line shall indicate the same media type as its corresponding media 
component in the original session and shall contain at least one codec that was negotiated during the original 
session. If the SC UE determines to remove a media component during the transfer, then the media line for 
this media component shall include a port number with value zero; and 

3) If the SC UE determines to add new media component(s) during the transfer, then one additional media line 
with the desired media type and codecs shall be added for each new media component. 
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If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request, then session transfer has not occurred 
and the call will continue in the original domains. 

1 1 .3 sec AS 

11 .3.1 Distinction of requests sent to tine SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to access transfer: 

SIP INVITE requests routed to the SCC AS containing a STI belonging to the subscribed user in the Replaces 
header field or Target-Dialog header field. In the procedures below, such requests are known as "SIP INVITE 
requests due to STI". 

SIP INVITE requests routed to the SCC AS containing either a static STN or an IMRN in the Request-URL In 
the procedures below, such requests are known as "SIP INVITE requests due to static STN". 

SIP INVITE requests routed to the SCC AS containing a static STI in the Request-URI and a STI in the 
Replaces header field. In the procedures below, such requests are known as "SIP INVITE requests due to two 
STIs". 

NOTE: The media streams that need to be transferred are identified using information described in the subsequent 
subclauses 11.3.2 and 11.3.3. 

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 

1 1 .3.2 SCC AS procedures for PS to PS+CS session continuity 

When the SCC AS receives a SIP INVITE request due to STI on the Target Access Leg, the SCC AS shall follow the 
PS-PS session continuity procedures specified in subclause 10.3.2. If the SIP INVITE request includes an active speech 
media component using CS bearer, then the SCC AS shall follow the procedures for ICS using Gm in 
3GPP TS 24.292 [4] subclause 7.4.2 to send the PSI DN to the SC UE and wait for the SC UE to set up CS bearer 
before sending re-INVITE to the remote end. 

When the SCC AS receives a SIP INVITE request due to static STN on the Target Access Leg, the SCC AS shall 
follow the PS-CS session continuity procedures specified in subclause 9.3.2. However, as the Source Access Leg 
contains media components other than speech component, the SCC AS does not initiate release for Source Access Leg. 

1 1 .3.3 SCC AS procedures for PS+CS to PS session continuity 

When the SCC AS receives a SIP INVITE request due to STI on the Target Access Leg, the SCC AS shall follow the 
PS-PS session continuity procedures specified in subclause 10.3.2. 

When the SCC AS receives a SIP INVITE request due to two STIs on the Target Access Leg, the SCC AS shall: 

associate the SIP INVITE request received on the Target Access Leg with two ongoing sessions: 

a) an ongoing SIP dialog on the PS Source Access Leg: This is done by matching the dialog ID present in the 
Replaces header field (see IETF RFC 3891 [10]) of the SIP INVITE request with an ongoing dialog. By an 
ongoing SIP dialog, it is meant a dialog for which a SIP 2xx response to the initial SIP INVITE request has 
been sent or received; 

b) a different ongoing SIP dialog with active full-duplex speech component: 

if the SCC AS is unable to associate the SIP INVITE request with either one of the above two dialogs, send a 
SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request relating to the access transfer and 
not process the remaining steps; and 

if the session transfer is possible: 
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a) follow the procedures defined in IETF RFC 3891 [10] for replacing the two sessions on the Source Access 
Legs with the SIP request received on the Target Access Leg, including terminating the two Source Access 
Legs by sending a SIP BYE request on each session towards the SC UE in accordance with 

3GPPTS 24.229 [2]; and 

b) send a SIP re-INVITE request towards the remote user using the existing established dialog. The SCC AS 
shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog 
with the remote user; and 

2) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to two 
STIs received on the Target Access Leg, by following the rules of the 3GPP TS 24.229 [2]. 



12 Roles for PS-CS session continuity, Single Radio 

12.1 Introduction 

This clause specifies the procedures for PS-CS session continuity in Single Radio VCC. Procedures are specified for the 
SC UE and the SCC AS. For SC UE or SCC AS not supporting ICS procedures, PS-CS session continuity in SR-VCC 
is only possible when the UE is active in a single session with full-duplex speech i.e. support of session transfer with 
more than one session containing full-duplex speech component is not provided. 

12.2 SC UE procedures for PS to CS session continuity, SR- 
VCC 

12.2.1 General 

The SC UE may be engaged in one or more ongoing IMS sessions before SR-VCC session continuity is performed. By 
an ongoing session, it is meant a session for which the SIP 2xx response for the initial SIP INVITE request to establish 
this session has been sent or received. 

12.2.2 ICS-based 

If: 

the Gm reference point is retained upon PS handover procedure; 

the SC UE is using ICS capabilities; and 

- SR-VCC procedures (as described in 3GPP TS 24.008 [8]) have been completed; 

the SC UE, in order to add Gm control for the newly established CS session, shall: 

send a SIP re-INVITE request for each speech session to be transferred, starting with the session with active full- 
duplex speech component that was most recently made active; and 

within the SDP offer indicate the media line for all active and held audio streams as an audio stream over circuit 
switched bearer in accordance with 3GPP TS 24.292 [4]. If the precondition mechanism is used, the SC UE shall 
indicate the related local preconditions as met. 

NOTE: Within SR-VCC the handover is performed on PS level. Due to this, the SIP dialog established over the 
source PS access network stays the same after SR-VCC procedures, e.g. the IP address of the UE, the 
Call-ID, the P-CSCF do not change. Therefore in this case a re-INVITE needs to be sent to add ICS- 
control for the CS bearer. 
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12.2.3 Not based on ICS 

After successful SR-VCC procedures (as described in 3GPP TS 24.008 [8]), if the SC UE is not using ICS capabilities, 
the SC UE shall replace the most recent active PS audio session with the newly established CS voice call. 

NOTE: In the case when ICS is not supported or used, only the most recent active audio call is transferred from 
PS to CS audio. 

If: 

the Gm reference point is retained upon PS handover; 
the SC UE is not using ICS capabilities; and 
- SR-VCC procedures (as described in 3GPP TS 24.008 [8]) have been completed; 
the SC UE shall: 

send a SIP re-INVITE request to the SCC AS as specified for media removal in subclause 13.2.1; and 
indicate in the SDP Offer the full-duplex speech media as removed. 

12.3 SCC AS 

1 2.3.1 SCC AS procedures for PS to CS session continuity, SR-VCC 

The SCC AS needs to distinguish between the following SIP INVITE requests to provide specific functionality for SR- 
VCC: 

SIP INVITE request routed to the SCC AS due to a STN-SR belonging to the subscribed user in the Request- 
URJ. These SIP INVITE requests originate from the MSC server and are used for CS bearer request as described 
in subclause 7.4.2.1 in 3GPP TS 24.292 [4]. In the procedures below, such requests are known as "SIP INVITE 
requests due to STN-SR". 

SIP re-INVITE request routed to the SCC AS containing one or more akeady existing media lines for audio 
indicate a CS bearer. In the procedures below, such requests are known as "SIP re-INVITE requests adding ICS 
control". 

SIP re-INVITE request routed to the SCC AS containing one or more already existing media lines for audio 
indicate the port set to "0". In the procedures below, such requests are known as "SIP re-INVITE requests for 
non-ICS control". 

When the SCC AS receives a SIP INVITE request due to STN-SR on the Target Access Leg, the SCC AS shall follow 
the PS-CS session continuity procedures specified in subclause 9.3.2 for the session with active full-duplex speech 
component that was most recently made active. However, the SCC AS does not initiate release for Source Access Leg. 

Editor's Note: It is FFS how the SCC AS coiTelates the SIP INVITE request due to STN-SR with the ongoing 
session. Usage of procedures in subclause 9.3.2 requires further study. 

When the SCC AS receives a SIP re-INVITE request for adding ICS control, the SCC AS shall follow the procedures as 
described for ICS using Gm in subclause 13.3.2. 

NOTE: When using the ICS controlled CS bearer, only one audio call can be active at a time. Nevertheless, 

several calls can be held in parallel. If the user decides to switch to another (previously held) call, the ICS 
controlled CS bearer is re-used for this call. Therefore no specific procedures for handling of held calls in 
the case of ICS controlled CS bearer are needed. 

When the SCC AS receives a SIP re-INVITE for non-ICS control, the SCC AS shall follow the media removal 
procedures as specified in subclause 13.3.1. As only the most recent active audio call is transferred from PS to CS 
audio, the SCC AS all drop all other previously existing audio session from this UE and indicate them accordingly in 
the SDP Offer sent within SIP re-INVITE requests towards the remote UE. 
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1 3 Roles for media adding/deleting 

13.1 Introduction 

This clause specifies the procedures for adding or deleting media to an existing multimedia session. Procedures are 
specified for the SC UE and the SCC AS. 

13.2 SCUE 

13.2.1 Adding or removing media tinrougin Gm 

If the SC UE wants to add or remove media to a session that was previously established using Gm, the SC UE shall 
follow the procedures defined in the 3GPP TS 24.229 [2] for adding/removing PS media and shall follow the 
procedures defined in the 3GPP TS 24.292 [4] for adding/removing CS media to the session. 

If the SC UE receives a SIP INVITE request from the remote end to add or remove media to a session that was 
previously established using Gm, the SC UE shall follow the procedures defined in the 3GPP TS 24.229 [2] for adding 
or removing PS media and shall foUow the procedures defined in the 3GPP TS 24.292 [4] for adding or removing CS 
media to the session. 

1 3.2.2 Adding Gm control to existing CS session 

The SC UE shall add Gm control to an existing CS session only when there is a single full-duplex speech session over 
CS. If there is more than one full-duplex speech session, the SC UE shall release all the ongoing sessions that are not 
currently active before attempting the procedures described in this section. 

If the SC UE wants to add Gm control to an existing CS session that was established without Gm, after registering with 
the IM CN subsystem, the SC UE shall send an initial SIP INVITE request over the PS access in accordance with 
3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE request as follows: 

- set the Request-URI to the tel URI of static STI; and 

set the SDP payload, in accordance with the procedures defined in 3GPP TS 24.292 [4], proposing an audio 
stream over a circuit switched bearer. The SC UE can optionally include additional PS media to the SDP in 
accordance to the procedures defined in 3GPP TS 24.229 [2]. 

Editor" s note: The contents of the SIP REGISTER are FFS. In particular, it is FFS how the UE chooses the correct 
public user identity to register to ensure that the implicit registration set of this public user identity 
contains the tel URI. 

Upon receiving a SIP 200 (OK) response, the SC UE shall treat the ongoing CS call as established using Gm and shall 
follow the "ICS UE using Gm" procedures defined in 3GPP TS 24.292 [4] for controlling the CS call. 

If the SC UE receives a new SIP INVITE request containing an audio stream over a circuit-switched bearer in the SDP 
and the PSI DN matches the B-party number of the ongoing CS call that was established without Gm, the SC UE shall: 

respond to the SIP INVITE request in accordance with the procedures defined in 3GPP TS 24.292 [4]; and 

treat the ongoing CS call as established using Gm and shall follow the "ICS UE using Gm" procedures defined in 
3GPP TS 24.292 [4] for controlling the CS call. 

13.3 SCC AS 

1 3.3.1 Adding or removing media tinrougin Gm 

When the SCC AS receives a SIP re-INVITE request from the SC UE or remote end to add/remove media to an existing 
session established using Gm, the SCC AS shall follow the procedures defined in 3GPP TS 24.229 [2] for adding or 
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removing PS media and shall follow the procedures defined in 3GPP TS 24.292 [4] for adding or removing CS media to 
the session. 

1 3.3.2 Adding Gm control to existing CS session 

If the sec AS receives a SIP INVITE request containing the STI in the Request-URI and the SC UE has an ongoing CS 
call, the sec AS shall: 

respond to the SIP INVITE request in accordance with the procedures defined in 3GPP TS 24.292 [4]; 

treat the ongoing CS call as established using Gm and shall follow the "SCC AS for service control over Gm" 
procedures defined in 3GPP TS 24.292 [4] for controlling the CS call; and 

- if the SIP INVITE request contains additional PS media, the SCC AS shall send a SIP re-INVITE request 
towards the remote end, including the newly added PS media, in accordance with the procedures defined in 

3GPPTS 24.229 [2]. 

The SCC AS shall add Gm control to an existing CS session only when there is a single full-duplex speech session over 
CS. If the SCC AS wants to add Gm control to an existing CS session that was established without Gm, the SCC AS 
shall send a new SIP INVITE request over the PS access in accordance with 3GPP TS 24.229 [2]. The SCC AS shall 
populate the SIP INVITE request as follows: 

set the Request-URI to the public user identity of the UE; and 

set the SDP payload, in accordance with the procedures defined in 3GPP TS 24.292 [4], proposing an audio 
stream over a circuit switched bearer. 

Upon receiving a SIP 200 (OK) response, the SCC AS shall treat the ongoing CS call as established using Gm and shall 
follow the "SCC AS for service control over Gm" procedures defined in 3GPP TS 24.292 [4] for controlling the CS 
call. 
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Annex A (informative): 
Example signalling flows 

A.1 Scope of signalling flows 

This annex gives examples of signalling flows for Service Continuity based on the Session Initiation Protocol (SIP) and 
SIP Events. 

These signalling flows provide detailed signalling flows, which expand on the overview information flows provided in 
3GPPTS 23.237 [9]. 

A.2 Introduction 
A.2.1 General 

The signalling flows provided in this annex follow the methodology developed in 3GPP TS 24.228 [3]. 

A.2. 2 Key required to interpret signalling flows 

The key to interpret signalling flows specified in 3GPP TS 24.228 [3] subclauses 4. 1 and 4.2 applies with the additions 
specified below: 

tel:+l-237-555-ll 1 1 represents the public user indentity of SC UE A. 

tel:+l-237-555-2222 represents the public user indentity of UE B. 

sip:sccasl. homel.net represents the Internet host of SCC AS. 

Each signalling flow table contains descriptions for headers where the content of the header is new to that signalling 
flow, as is already performed in 3GPP TS 24.228 [3]. 

However, 3GPP TS 24.228 [3] includes extensive descriptions for the contents of various headers following each of the 
tables representing the contents of the signalling flows. Where the operation of the header is identical to that shown in 
3GPP TS 24.228 [3], then such text is not reproduced in the present document. 

Additional text may also be found on the contents of headers within 3GPP TS 24.228 [3] in addition to the material 
shown in the present document. 

In order to differentiate between messages for SIP and media, the notation in figure A.2-1 is used. 

INVITE 
► SIP message 



SETUP 
► CS message 



Media over a PS connection 



Media over a CS connection 



Figure A.2-1 : Signalling flow notation 



£75/ 



3GPP TS 24.237 version 8.0.0 Release 8 



26 



ETSI TS 124 237 V8.0.0 (2009-01) 



A.3 Signalling flows for registration 
A.3.1 Introduction 

When using CS access for media and to make use of the IMS ISC procedures, the SC UE is registered in IM CN 
subsystem and the signalling flows are defined in 3GPP TS 24.292 [4] subclause A.2. 

When initiating a CS call, the SC UE can be registered in the CS domain as defined in 3GPP TS 24.008 [8]. 

Whenever the UE acquires IP connectivity via an IP-CAN, the signalling fiows for registration in the IMS are defined 

in3GPPTS24.228[3]. 

A.3. 2 Signalling flows for multiple registration 

The signalling flows shown in figure A. 3. 2-1 gives an example when a UE connects to different IP-CAN respectively 
and performs multiple registrations. 
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Figure A.3.2-1 Signalling flows for multiple registrations 

1. SIP REGISTER request (UE to P-CSCF#1)-See example in table A.3.2-1 

UE sends the SIP REGISTER request via the 1P-CAN#1. 
NOTE 1: For clarity, the unprotected SIP REGISTER request via the 1P-CAN#1 is not shown in this example. 
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Table A.3.2-1SIP REGISTER request (UE to P-CSCF#1) 



REGISTER sipiregistrar .homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: <sip :userl_publicl@homel .net>; tag=4f a3 

To : <sip :userl_publicl@homel .net> 

Contact: <sip: [5555 :: aaa :bbb: ccc :ddd] : 1357;comp=sigcomp>; reg-id=l; 

+sip. instance="<urn:uuid: 00000000-0000-1000-8000-AABBCCDDEEFF>" ; expires=600000 
Call -ID: apb03a0s0 9dkjdfglkj4 9111 
Authorization: Digest username="userl_private@homel .net" , realm="registrar .homel .net" , 

nonce=base64 (RAND + AUTN + server specific data), algorithm=AKAvl-MD5 , 

uri=" sip: registrar .homel .net" , response="662 9f ae493 93a053 97450978507c4ef 1" 
Security-Client: ipsec-3gpp; alg=hmac-sha-l-96 ; spi-c=23456789; spi-s=12345678 ; port-c=246e 

port-s=1357 
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c = 98765432 ; spi -s =8765432 1 ; port- 

c=8642; port-s=7531 
Require: sec-agree 
Proxy-Require: sec-agree 
CSeq: 2 REGISTER 
Supported: path, outbound, gruu 
Content-Length: 



2. SIP REGISTER request (P-CSCF#1 to I-CSCF)-See example in table A.3.2-2 

After performing the DNS query, the P-CSCF#1 forwards the REGISTER request towards I-CSCF. The P-CSCF 
adds a Path header with a flow token and includes the 'ob' parameter 

Table A.3.2-2 SIP REGISTER request (P-CSCF#1 to I-CSCF) 



REGISTER sip:registrar .homel .net SIP/2.0 

Via: SIP/2. 0/UDP pcscfl.visitedl.net;branch=z9hG4bK240f34 .1, SIP/2. 0/UDP 

[5555 : :aaa:bbb: ccc :ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 
Max-Forwards: 69 
P-Access-Network-Info : 

Path: <sip: VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib®pcscf 1 .visitedl .net ; lr ;ob> 
Require: path 

P-Visited-Network-ID : "Visited Network Number 1" 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=02 3 551024" 
From: 
To: 

Contact : 
Call-ID: 
Authorization: Digest username="userl_private@homel .net" , realm="registrar .homel .net" , 

nonce=base64 (RAND + AUTN + server specific data), algorithm=AKAvl-MD5 , 

uri=" sip: registrar .homel .net" , response="662 9f ae493 93a053 97450978507c4ef 1" , integrity- 

protected="yes" 
CSeq: 

Supported: 
Content-Length : 



3. SIP REGISTER request (I-CSCF to S-CSCF) 

The I-CSCF forwards the SIP REGISTER request to the S-CSCF. 

4. SIP 200 (OK) response (S-CSCF to I-CSCF)-See example in table A.3.2-4 

The S-CSCF sends a SIP 200 (OK) response to the I-CSCF indicating that Registration was successful. AS the 
URI in the first path header field has an "ob" URI parameter, it include a Require header with the option-tag 
"outbound". 
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Table A.3.2-4: SIP 200 (OK) response (S-CSCF to l-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_p.homel.net , ■branch=z9hG4bK351g45 .1, SIP/2. 0/UDP 
pcscf 1 . visitedl -net ;branch=z9hG4bK24 0f 34 . 1 , SIP/2 . 0/UDP 
[5555 : :aaa:bbb: ccc :ddd] : 1357 ; comp=sigcomp ; branch=z9hG4bKnashds7 

Path: <sip : termopcscf 1 .visitedl .net; lr;ob> 

Service-Route : <sip : origOscscf 1 . homel . net ; lr> 

From: 

To: 

Call-ID: 

Contact: <sip: [5555 :: aaa :bbb : ccc :ddd] : 1357;comp=sigcomp>; 
pub-gruu=" sip: user l_publicl@homel .net ;gr=urn:uuid: f81d4fae-7dec-lld0-a765-00a0c91e6bf6" 
; temp -gruu=" sip: tgruu. 7hs==jd7vnzga5w7f ajsc7-ajd6f abzOf 8g5@example . com;gr" 
; +s ip . ins tance= " < urn :uuid:00000000-0000-1000-8000 -AABBCCDDEEFF> " 
;expires=G00000 

CSeq: 

Supported: path, outbound 

Require : outbound 

Date: Wed, 11 July 2001 08:49:37 GMT 

P-Associated-URI : <sip :userl_public2@homel .net>, <sip :userl_public3®homel .net>, <sip:+l-212- 
555-llll@homel .net ; user =phone> 

Content-Length : 



5-6. SIP 200 (OK) response (I-CSCF to UE) 

The I-CSCF forwards the SIP 200 (OK) response to the UE via P-CSCF#1. 
Editors" Note: The procedure of subscription to the registration-state event package is to be added. 

7. SIP REGISTER request (S-CSCF to SCC AS)-See example in table A.3.2-7 

After UE successfully registered in the IM CN subsystem, the S-CSCF sends a third party REGISTER request to 
the SCC AS based on the initial filter criteria it received. 

Table A.3.2-7: SIP REGISTER request (S-CSCF to SCC AS) 

REGISTER sip: sccas.homel.net /2 . 

Via: SIP/2. 0/UDP scscfl. homel. net;branch=z9hG499ffhy 

Max-Forwards: 70 

From: <sip : scscfl . homel . net> ; tag=538ya 

To : <sip : userl_publicl®homel . net> 

Call-ID: lasdaddlrf jflslj40a222 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Contact: <sip : scscfl .homel .net>; expires=600000 

CSeq: 87 REGISTER 

Content-Length : 

8. SIP 200 OK response (SCC AS to S-CSCF) 

The SCC AS generates the SIP 200 (OK) response to the third party SIP REGISTER request. 

9. UE connects to a new IP-CAN 

The UE connects to a new IP-CAN and will perform the registration via the new IP-CAN. 

10. SIP REGISTER request (UE to P-CSCF#2)- See example in table A.3.2-10 

UE sends the unprotected SIP REGISTER request via the new IP-CAN to P-CSCFh-2 which in this example is a 
different one with previous registration. 
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Table A.3.2-10: SIP REGISTER request (UE to P-CSCF#2) 



REGISTER sipiregistrar .homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555: : aaa :bbb : ccc : eee] ;comp=sigcomp;branch=z9hG4bKnasiuen8 

Max-Forwards: 70 

P-Access-Network-Info: IEEE-802 . lib 

From: <sip :userl_publicl@homel .net>; tag=2hiue 

To : <sip :userl_publicl@homel .net> 

Contact: <sip: [5555 :: aaa :bbb : ccc : eee] ;comp=sigcomp>; reg-id=2; 

+sip. instance="<urn:uuid: 00000000-0000-1000-8000-AABBCCDDEEFF>;expires=600000 
Call-ID: E05133BD26DD 
Authorization: Digest username="userl_private®homel .net" , realm="registrar .homel .net" , 

nonce="", uri= "sip: registrar .homel .net" , response="" 
Security-Client: ipsec-3gpp; alg=hmac-sha-l-96 ; spi-c=23456789; spi-s=12345678 ; port-c=1234; 

port-s=5678 
Require: sec-agree 
Proxy-Require: sec-agree 
CSeq: 1 REGISTER 
Supported: path, outbound, gruu 
Content-Length: 



11-12. SIP REGISTER request (P-CSCF#2 to S-CSCF) 

The P-CSCF forwards the SIP REGISTER request towards S-CSCF via I-CSCF. Likewise in message #2, P- 
CSCF#2 adds a Path header with flow token and 'ob' parameter. 

13-15. SIP 401 (Unauthorized) response (S-CSCF to UE) 

The authentication challenge is sent in the SIP 401 (Unauthorized) response towards the UE. 
16-18. SIP REGISTER request (UE to S-CSCF) 

The UE sends the protected SIP REGISTER request towards S-CSCF using contact#2. 
19-21. SIP 200 (OK) response (S-CSCF to UE) 

The S-CSCF sends a SIP 200 (OK) response towards the UE indicating that registration was successful. 
Editors" Note: The procedure of subscription to the registration-state event package is to be added. 

22. SIP REGISTER request (S-CSCF to SCC AS) 

The S-CSCF sends a third party REGISTER request to the SCC AS based on the initial filter criteria it received. 

23. SIP 200 (OK) response (SCC AS to S-CSCF) 

The SCC AS generates the SIP 200 response to the third party REGISTER request. 

A.4 Signalling flows for call origination 
A.4.1 Session origination for CS calls 

Figure A.4. 1-1 shows the origination of a call from a SC UE using CS bearers. In this example the call is anchored by 
the SCC AS at the originating side in the IM CN subsystem. 

NOTE: The signalling flow for session origination using CS media for UE with ICS capabilities using Gm 
reference point can be described in 3GPP TS 24.292 [4]. 
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Figure A.4.1-1 Session origination for CS calls 

The details of the signalling flows are as follows: 

1 . Initiate CS call setup: 

SC UE A initiates a CS call following the procedures specified in 3GPP TS 24.008 [8]. 

2. SIP INVITE request (interworking entities to intermediate IM CN subsystem entities) - see example in 
table A.4.1-2. 
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Table A.4.1-2: SIP INVITE request (interworking entities to intermediate IIVI CN subsystem entities) 



INVITE tel:+l-237-555-3333 SIP/2.0 

Via: SIP/2 . 0/UDPmgcfl .homel .net; branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip : icscf 1 . homel . net : 7531 ; Ir ; comp=sigcomp> 

P-Asserted-Identity: <tel: +l-237-555-llll> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

Privacy: none 

From: <tel: +l-237-555-llll>; tag=171828 

To: <tel:+l-237-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Accept -Contact : * ; +g. 3gpp . icsi-ref="urn%3Aurn-xxx%3gpp- service . ims . icsi .mmtel" 

P- Asserted- Service : urn:urn-xxx: 3gpp- service . ims .icsi .mmtel 

Contact : <sip :mgcf 1 .homel .net ;gr>; +g. 3gpp . icsi -ref="urn%3Aurn-xxx%3gpp- service . ims .icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Accept : 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 20 



Request-URI: Contains the IMRN, as obtained from CS Networks signalling.. 
SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

3. SIP 100 (Trying) reponse (intermediate IM CN subsystem entities to interworking entities) 

The intermediate IM CN subsystem entities respond to interworking entities with a SIP 100 (Trying) response. 
There is no SC specific content in this response. 

4. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) - see example in table A.4.1-5. 
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Table A.4.1-5: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 



INVITE tel:+l-237-555-3333 SIP/2.0 

Via: SIP/2 .0/UDP mgcfl.homel.net ;branch= z9hG4bKnashds7, SIP/2. 0/UDP 

icscf 1 .homel .net ;branch=z9hG4bKdwe534, SIP/2. 0/UDP scscf 1 .homl .net ;branch= z9hc4bkd2b23 . 1 
Max-Forwards: 68 

Route: <sip : sccasl .homel .net : lr>, Record-Route: <sip : scscf 1 .homel .net ; lr> 
P-Asserted- Identity : 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi="type 

3homel .net" ; orig-ioi= "homel .net" 
Privacy: 
From: 
To: 

Call-ID: Cseq: Supported: 
Accept-Contact : 
P-Asserted-Service : 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 



6. SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 
There is no SC specific content in this response. 

7. SCC AS anchors the call: 
The SCC AS anchors the call. 

8. SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.4.1-8 

The SCC AS acting as a routing B2BUA, generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards UE B via the 
intermediate IM CN subsystem entities. 
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Table A.4.1-8: SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE tel:+l-237-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP sccasl .homel .net;branch=z9hG4bKnas34r5 

Max-Forwards: 70 

Route: <sip : scscfl .homel .net : lr> 

P-Asserted- Identity : 

P- Charging- Function- Addresses : ccf = [5555: :b9 9:c88:d7 7:e66] ; ccf=[5555: :a55 :b44 :c3 3 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
P-Charging-Vector : icid-value="AyretyU0dm+SO2IrT5tAFrbHLso=023551024" ; orig- 

ioi="type3homel .net" 
Privacy: none 

From: <tel: +l-237-555-llll>; tag=569812 
To: 

Call-ID: Cseq: 

Supported: lOOrel, precondition 
Accept-Contact : 
P-Asserted-Service : 
Contact : 

Allow: Content-Type: Content-Length: 
v= 
o= 



9. SIP 100 (Trying) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities respond to the SCC AS with a SIP 100 (Trying) response. 
There is no SC specific content in this response. 

10. SIP INVITE request (intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities route the SIP INVITE request to UE B. 

11-12. SIP 180 (Ringing) response (UE B to SCC AS via intermediate IM CN subsystem entities) 

UE B responds to the received SIP INVITE request with a SIP 180 (Ringing) response. The response contains no 
SDP body and contains no SC specific content. 

13-14. SIP 180 (Ringing) response ( SCC AS to interworking entities via intermediate IM CN subsystem 
entities) 

The response contains no SDP body and contains no SC specific content. 

15. Alerting the user: 

The call is successfully delivered to the terminating UE, which begins alerting the user. 

16. SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities) - see example in table A.4.1-16 
The terminating side sends an SDP answer in a SIP 200 (OK) response to the received SIP INVITE request. 
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Table A.4.1-16: SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2 . 0/UDP pcscf2 .visited2 .net : 5 088 ;comp=sigcomp;branch=z9hG4bK361k21 . 1, 

scscf2 .homel .net ;branch=z9hG4bK764z87 . 1, icscf 1 .homel .net ;branch=z9hG4bK8 71yl2 . 1, 
SIP/2 . 0/UDP scscfl .homel .net;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 
sccasl .homel . net ; branch= z9hG4bKnas34r5 

Record- Route : <sip ipcscf 2 . visited2 .net : 50 8 8 ; lr;comp=sigcomp>, <sip:scscf2 . visited2 .net; lr>, 
<sip: scscfl .homel .net ; lr> 

Privacy: none 

From: <tel: +l-237-555-llll>; tag=569812 

To: <tel: +1-237- 555 -2222 >;tag=8321234 

Call-ID: 

CSeq: 

Supported: gruu 

Contact : <sip: user2_publicl@home2 .net ;gr=urn:uuid: 2ad8950e-48a5-4a74-8d99- 
ad76cc7f c74 ; comp=sigcomp>;+g.3gpp.icsi-ref="urn%3Aum-xxx%3gpp-service.ims.icsi.mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933623 2987933623 IN IP6 5555 : : ggg : f f f : aaa : bbb 

s = - 

c=IN IP6 5555 : :ggg:fff :aaa:bbb 

t = 

m=audio 3456 RTP/AVPF 97 96 

a=acfg:l t=l 

b=AS:2 5.4 

a=curr:qos local sendrcv 

a=curr:qos remote sendrcv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=maxptime : 2 



17. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The SIP 200 (OK) response from UE is routed towards the SCC AS. 

18-19. SIP 200 (OK) response (SCC AS to interworking entities via intermediate IM CN subsystem entities) 

The SDP answer received in the SIP 200 (OK) response is routed to the interworking entities via the 
intermediate IM CN subsystem entities. 

20. SCC AS completes call setup with CS bearer 

The SCC AS completes call setup with CS bearer following the standard procedures in 3GPP TS 24.008 [8]. 
21-22. SIP ACK request (interworking entities to SCC AS via intermediate IM CN subsystem entities) 

The interworking entities send a SIP ACK request to the SCC AS via the intermediate IM CN subsystem entities. 
There is no SC specific content in this response. 
23-24. SIP ACK request (SCC AS to UE B via intermediate IM CN subsystem entities) 

The SCC AS sends a SIP ACK request to UE B via the intermediate IM CN subsystem entities. 
There is no SC specific content in this response. 
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A.5 Signalling flows for call termination 
A. 5.1 Session termination using CS media 

Figure A.5. 1-1 shows the termination of a call from a SC UE using CS bearers. In this example the call is anchored by 
the sec AS at the terminating side in the IM CN subsystem. 

NOTE: The signalling flow for session termination using CS media for UE with ICS capabilities using Gm 
reference point can be described in 3GPP TS 24.292 [4]. 
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Figure A.5. 1-1 Session termination withi CS media 

The details of the signalling flows are as follows: 

1. SIP INVITE request (UE B to intermediate IM CN subsystem entities) - see example in table A.5.1-1. 
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Table A.5.1-1 : SIP INVITE request (UE B to intermediate IM CN subsystem entities) 



INVITE tel:+l-237-555-llll SIP/2.0 

Via: SIP/2. 0/UDP [5555: :aaa:bbb:ccc:ddd] :1357; branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf 2 .home2 .net : 7531; lr;comp=sigcomp>, <sip : origOscscf 2 .home2 .net; lr> 

P-Preferred-Identity: <tel: +l-237-555-2222> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

P-Access-Network-Info : 

Privacy: none 

From: <tel: +l-237-555-2222>; tag=171828 

To: <tel:+l-237-555-llll> 

Call -ID: Cb03a0s09a2sdfglkj4903 3 3 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu, 199 

Accept -Contact : * ; +g . 3gpp . icsi-ref="urn%3Aurn-xxx%3gpp- service . ims . icsi .mmtel" 

P- Preferred- Service : urn:urn-xxx: 3gpp- service . ims .icsi .mmtel 

Contact : <sip:UEB@home2 . net ;gr=urn :uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6>; 

+g. 3gpp. icsi_ref="urn%3Aurn-xxx%3gpp- service . ims .icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Accept: application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



Request-URI: the SIP URI or tel URI of the called party. In this example the tel URI of the called party is 
included in the tel URI. 

2. SIP 100 (Trying) reponse (intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities respond to UE B with a SIP 100 (Trying) response. 
There is no SC specific content in this response. 

3. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

4. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) - see example in table A.5.1-4. 
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Table A.5.1-4: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 



INVITE tel:+l-237-555-llll SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

icscf 1 .homel .net ;branch=z9hG4bKdwe534 , SIP/2 . 0/UDP scscf 2 .hom2 .net ;branch=z9hG4bKtehui7 , 

SIP/2 .0/UDP pcscf2 .home2 .net ;branch=z9hG4bK123ey67 , SIP/2 .0/UDP 
[5555: :aaa:bbb:ccc:ddd] :1357; branch=z9hG4bKnashds7 
Max-Forwards: 66 

Route: <sip : sccasl .homel .net : lr> 
P-Asserted-Identity: <tel: +l-212-555-2222> 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi="type 

Shomel .net" ; orig-ioi= "homel .net" 
P-Access-Network-Inf o : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 
Accept : 
Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 
t= 



5. SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 
There is no SC specific content in this response. 

6. SCC AS anchors the call: 
The SCC AS anchors the call. 

7. SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.5.1-7 

The SCC AS acting as a routing B2BUA, generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards SC UE A via the 
intermediate IM CN subsystem entities. 
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Table A.5.1-7: SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE tel:+l-237-555-llll SIP/2.0 

Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r5 , 

scscf 1 .homel .net ;branch=z9hG4bK3 3 2b2 3 .1, SIP/2 . 0/UDP icscf 1 .homel .net ;branch=z9hG4bKdwe534 , 

SIP/2. 0/UDP scscf2 .hom2 .net;branch=z9hG4bKtehui7, SIP/2. 0/UDP 

pcscf2 .home2 .net;branch=z9hG4bK123ey67, SIP/2. 0/UDP [5555 : :aaa:bbb: ccc :ddd] :1357; 

branch= z 9hG4bKnashds 7 
Max-Forwards: 65 

Route: <sip : scscf 1 .homel .net : lr> 
P-Asserted- Identity : 
P- Charging- Function- Addresses : ccf = [5555: :b9 9:c88:d7 7:e66] ; ccf = [5555 : :a55 :b44 :c3 3 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig- 

ioi="type3homel .net" 
P-Access-Network-Info : 
Privacy: 

From: <tel: +l-237-555-2222>; tag=569812 
To: 

Call-ID: 
Cseq: 

Supported: 
Accept-Contact : 
P-Asserted-Service : 
Contact: Allow: 
Accept : 
Content-Type : 
Content-Length : 



8. SIP 100 (Trying) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities respond to the SCC AS with a SIP 100 (Trying) response. 
There is no SC specific content in this response. 

9. SIP INVITE request (intermediate IM CN subsystem entities to interworking entities) 

The intermediate IM CN subsystem entities route the SIP INVITE request to interworking entities. 

10. SIP 100 (Trying) response (interworking entities to intermediate IM CN subsystem entities) 

The interworking entities respond to intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 

There is no SC specific content in this response. 

1 1 SC UE A setups the session with CS bearer: 

The SC UE determines that the session is to be setup with CS bearer using standard procedures in 
3GPPTS 24.008 [8]. 

12-13. SIP 180 (Ringing) response (interworking entities to SCC AS via intermediate IM CN subsystem 
entities) 

The interworking entities respond to the received SIP INVITE request with a SIP 180 (Ringing) response. 
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The response contains no SDP body and contains no SC specific content. 
14-15. SIP 180 (Ringing) response (SCC AS to UE B via intermediate IM CN subsystem entities) 

The SCC AS forwards the SIP 180 (Ringing) response to UE B via intermediate IM CN subsystem entities. 

16. SIP 200 (OK) response (interworking entities to intermediate IM CN subsystem entities) - see example in 
table A.5.1-16 

The interworking entities send an SDP answer in a SIP 200 (OK) response to the received SIP INVITE request. 

Table A.5.1-16: SIP 200 (OK) response (interworking entities to intermediate IM CN subsystem 

entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP mscl.homel.net;branch=z9hG4bK332b23 .1 

P-Access-Network-Info : 

Privacy: none 

From: <tel: +l-237-555-2222>; tag=569812 

To: <tel: +1-237- 555 -llll>;tag=8992765 

Call-ID: 

CSeq: 

Contact: <sip :mgcf 1 .homel .net ; gr> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933623 2987933623 IN IP6 5555 : : ggg : f f f : aaa : bbb 

s = - 

c = IN IP6 5555 : :ggg:fff :aaa:bbb 

t = 

m=audio 3456 RTP/AVPF 97 96 

a=acfg:l t=l 

b=AS:25 .4 

a=curr:qos local sendrcv 

a=curr:qos remote sendrcv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=maxpt ime : 2 



17-19. SIP 200 (OK) response (intermediate IM CN subsystem entities to UE B via SCC AS) 

The SIP 200 (OK) response is routed towards the UE B. 
20-21. SIP ACK request (UE B to SCC AS via intermediate IM CN subsystem entities) 

The UE B sends a SIP ACK request to the SCC AS via the intermediate IM CN subsystem entities. 

There is no SC specific content in this response. 

22-23. SIP ACK request (SCC AS to interworking entities via intermediate IM CN subsystem entities) 

The SCC AS sends the SIP ACK request to interworking entities via the intermediate IM CN subsystem 
entities. 

There is no SC specific content in this response. 



A. 6 Signalling flows for PS-CS session continuity 
A.6. 1 PS-CS access transfer: CS-PS 

In this example, SC UE A has an ongoing session with remote UE B over CS bearer before access transfer. When SC 
UE connects to an IP-C/VN, it decides to transfer the session over the new IP-C/VN. 
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Figure A.6.1-1 : Signalling flow for PS-CS Access Transfer: CS to PS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. SC UE A has an ongoing session with remote UE B 

The call has been anchored at the SCC AS which is in the HPLMN of originating SC UE A. 

2. SC UE A connects to a new IP-CAN: 

The SC UE A decides to transfer the session over the new IP -CAN. The UE A obtains an IP address that it will 
use for the signalling and media. It registers with the S-CSCF over the new IP-CAN using standard registration 
procedure and reserves resources in the new IP-CAN. 

3. SIP INVITE request (SC UE A to intermediate IM CN subsystem entities) - see example in table A.6.1-3 

The SC UE A sends an initial INVITE request to request the new call replaces the existing call. 
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Table A.6.1-3: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE sip : domain. xf erOsccas .homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : sip :pcscf 1 .homel .net : 75 31; lr;comp=sigcomp>, <sip :orig@scscf 1 .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: IEEE-802 . lib 

Privacy: none 

From: <sip :userl_publicl®homel .net>; tag=171828 

To: <tel:+l-237-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj4 902 3 7 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; portl=7531 

Contact : <sip :userl_publicl®homel .net ;gr=hdg7777ad7af lzig8sf 7>;comp=sigcomp 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; application/3gpp-ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



4. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC. 

6. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

7. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities)- See example in table A.6.1-7 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID headers from one side of the B2BUA to the other. The SIP re-INVITE request contains the 
SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP INVITE request from the 
UE A (Step 3). 
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Table A.6.1-7: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE <sip: [5555 : :eee:fff :aaa:bbb] :8805 SIP/2.0 

Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 

Max- Forwards : S7 

Route: <scscf 1 .homel .net ; Ir >, <sip : scscf 2 .home2 .net ; lr>, <sip :pcscf 2 . visited2 .net ; lr> 

P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net>, <tel : +l-237-555-llll> 

P-Access-Network-Info: IEEE-802 . lib 

Privacy: none 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 

P-Charging-Function-Addresses : 

From: <sip :userl_publicl@homel .net>; tag=1717777 

To: <tel:+l-237-555-2222>, tag=4321 

Call -ID: dcl4bltl0b3teghmlk50132 3 7 

Cseq: 111 INVITE 

Supported: precondition, lOOrel 

Contact :<sip: [7777: :eee :ddd: ccc : aaa] > 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



8. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 
9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate IM CN subsystem entities) 

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
11-12: SIP ACK request (SCC AS to UE B via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE B. 
13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 
17. Media paths between UE A and UE B 

The media path is using the new IP-CAN. 
18-19. SIP BYE request (SCC AS to interworking entities via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the CS bearer, by sending a BYE request. 
20-22. ISUP Message 

Upon receiving the DISCONNECT request, the SC UE A relinquishes all resources pertaining to the CS bearer. 
23-24. SIP 200 (OK) response (Interworking entities to SCC AS via intermediate IM CN subsystem entities) 
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A.6.2 PS-CS access transfer: PS-CS 

In this example, SC UE A has an ongoing session with remote UE B over PS bearer before access transfer which is 
anchored at SCC AS. When the SC UE attaches to the CS domain, it decides to transfer the session over the CS bearer 
without ICS capabiUty. 
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Figure A.6.2-1 Signalling flow for PS-CS access transfer: PS-CS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. SC UE A is on an active session with UE B: 

There is an ongoing IP bearer between the SC UE and the remote end UE B. The call is achored at SCC AS. 

2. SC UE A attaches to the CS domain 

The SC UE attaches to the CS domain and decides to transfer the session over the CS bearer. 

3. CC SETUP messages 
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The SC UE sends the CS SETUP message with the static STN as the called party number. 

4. SIP INVITE request (Interworking entities to Intermediate IM CN subsystem entities) -see example in 
Table A.6.2-4 

Table A.6.2-4: SIP INVITE request (interworking entities to intermediate IM CN subsystem entities) 



INVITE tel: +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcfl.homel.net;branch=z9hG4bk731b87 

Max- Forwards : 7 

Route : <sip : icscf 1 . homel . net ; lr> 

P-Asserted-Identity: <tel: +l-237-555-llll> 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

Privacy: none 

From: <tel: +l-237-555-llll>; tag=171828 

To: <tel: +l-237-555-3333> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Accept -Contact : * ; +g. 3gpp . icsi-ref="urn%3Aurn-xxx%3gpp- service . ims . icsi .mmtel" 

P- Asserted- Service : urn:urn-xxx: 3gpp- service . ims .icsi .mmtel 

Contact : <sip :mgcf 1 .homel .net ;gr>; +g. 3gpp . icsi-ref="urn%3Aurn-xxx%3gpp- service . ims .icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 



Request-URI: contains the IMRN, as obtained from CS networks signalling. 
SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

5. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

6. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

7. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

8. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) -see example in table A.6.2- 
8 

The SCC AS acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards UE B via the 
intermediate IM CN subsystem entities. 
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Table A.6.2-8: SIP re-INVITE request (SCC AS to intermediate IIVI CN subsystem entities) 



INVITE sip: user2_publicl@home2 .net ;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad76cc7f c74 SIP/2.0 

Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r5 

Max-Forwards: S7 

Route: <sip : scscfl .homel .net : lr> 

P-Asserted-Identity: <tel: +l-237-555-llll> 

P- Charging- Function- Addresses : ccf = [5555: :b9 9:c88:d7 7:e66] ; ccf=[5555: :a55 :b44 :c3 3 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
P-Charging-Vector : icid-value="AyretyU0dm+SO2IrT5tAFrbHLso=023551024" ; orig- 

ioi="type3homel .net" 
Privacy: none 

From: <tel: +l-237-555-llll>; tag=569812 
To: <tel:+l-237-555-2222>; tag=26545 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 
Contact : 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t=0 

m=audio 3456 RTP/AVPF 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 

m=message TCP/MSRP 98 

a=accept-types : text/plain 



9. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 

10. SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE B has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

11. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP re-INVITE request to 
the SCC AS in the originating network. 

12-13. SIP ACK request (SCC AS to UE B via IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE B. 

14-15. SIP 200 (OK) response (SCC AS to interworking entities via IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response to the interworking entities. 

16. ISUP CONNECT message (interworking entities to SC UE A) 

17. ISUP CONNECT Response message (SC UE A to interworking entities) 

18-19. SIP ACK request (interworking entities to SCC AS via IM CN subsystem entities) 
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The interworking entities generate the SIP ACK request to the SIP 200 (OK) response, and forward it to the SCC 
AS. 

20. Media paths between SC UE A and UE B: 

The CS bearer is setup while the PS bearer is still existing. 

21-22: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the old IP -CAN, by sending a BYE request to the 
UEA. 

23-24. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the BYE request over the old IP -CAN, the SC UE A sends a SIP 200 (OK) response over the old 
IP-CAN to the SCC AS. Subsequently, the SC UE A relinquishes all resources pertaining to the old IP -CAN. 

25. Media paths between SC UE A and UE B 

Finally, the session is transferred from PS bearer to CS bearer. 



A.7 Signalling flows for PS-PS session continuity 

Editor's note: This subsclause will contain signalling flows related to PS-PS session continuity. 

A.7.1 Introduction 

A. 7. 2 PS-PS access transfer with full media transfer 

The signalling flows shown in figure A. 7. 2-1 describes the PS-PS access transfer procedure when all media of an 
ongoing communication session and the associated signalling are transferred from one contact address of an UE to a 
different contact address of the same UE. No lower-level mechanism to support the session continuity is assumed or 
need. 

In this example the UE-1 is on an active multimedia session with the UE-2 via one IP-CAN. After changing to a new 
IP -CAN, obtaining a new IP address, and discovering a P-CSCF, the UE-1 reserves resources in new IP-CAN prior to 
initiating the PS-PS access transfer procedure. When the PS-PS access transfer procedure is completed, the UE-1 
continues the multimedia session with the UE-2 on the new IP-CAN. In this example, when attaching to the new IP- 
CAN, it is irrelevant whether the UE-1 uses the same P-CSCF or a new P-CSCF. 

NOTE 1: This scenario requires that the UE-1 and the IMS network support simultaneous multiple registrations and 
requires that the UE-1 supports dual mode operation. 

NOTE 2: In this example flow, each call leg is uniquely identified with a respective dialog identifier consisting of 
the Call-ID, From tag, and To tag. 
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Figure A.7.2-1 : Signalling flow for session handover 

NOTE 3: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. UE-1 is on an active session with UE-2 

The UE-1 is in an active session with the UE-2. The call is anchored in the SCC AS. It is irrelevant which 
endpoint initiated the call. Each call leg is uniquely identified with a respective dialog identifier. The call lej 
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over old IP-CAN is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To 
tag=77432r'. The UE-1 and UE-2 exchange media over the old IP-CAN, which is maintained while the UE-1 
initiates the handover procedure. 

2. UE-1 connects to new IP-CAN 

The UE-1 determines that a handover of the session is required. The UE-1 connects to the new IP-CAN. The 
UE- 1 obtains an IP address that it will use for the signalling and media. 

3. UE-1 registers with intermediate IM CN subsystem entities over new IP-CAN 

The UE-1 registers with the S-CSCF over the new IP-CAN using the standard registration procedure. Depending 
on the UE-1 configuration, the discovery of the P-CSCF in the new IP-CAN may be needed. 

4. UE-1 acquires resources in new IP-CAN 

Based on the UE-1 and new IP -CAN capabilities, the UE-1 decides to use the same codec that was used over the 
old IP -CAN. The UE-1 reserves resources (e.g. QoS) in the new IP -CAN that will be needed for the signalling 
and transferred media, prior to sending the initial SIP INVITE request. 

5. SIP INVITE request (UE-1 to intermediate IM CN subsystem entities) - see example in table A.7.2-5 

The UE-1 sends initial SIP INVITE request with a new SDP offer to the UE-2 that indicates that the new call 
replaces the existing call. The initial SIP INVITE request specifies new contact address that will be used for the 
signalling and media over the new IP -CAN. Upon sending the initial SIP INVITE request, the UE-1 is ready to 
receive the RTP packets either over the new IP-CAN or the old IP -CAN. The RTP packets may arrive over the 
new IP -CAN prior to the UE-1 receiving the SIP 200 (OK) response for the initial SIP INVITE request. 

Table A.7.2-5: SIP INVITE request (UE-1 to intermediate IM CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : sip :pcscf 1 .homel .net : 75 31; lr;comp=sigcomp>, <sip :orig@scscf 1 .homel .net; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: IEEE-802 . lib 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171828 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Require: sec-agree; replaces 

Replaces: me03a0s09a2sdfgjkl491777; to-tag=774321; f rom-tag=64727891 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; portl=7531 

Contact: < sip: [5555: : aaa :bbb : ccc : ddd] : 1357> ; comp = sigcomp 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; application/3gpp-ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2 , 5, 7; mode- change -period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 



Request-URI: the tel-URI of the destination, i.e. the UE-2. 

Require: the "replaces" option tag indicate that the support for Replace header is required. 
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Replaces: specifies the existing call that will be replaced with the new call. 

SDP: specifies the new IP address that the UE-1 has acquired in the new IP-CAN, and indicates that the 
resources in the new IP -CAN have been acquired. 

Contact: specifies the IP address that the UE-1 has acquired in the new IP -CAN, and it will use for this call. 

6. Evaluation of initial filter criteria 

Upon the evaluation of the initial filter criteria, as this is an originating initial SIP INVITE request for a 
registered user, the S-CSCF routes the initial SIP INVITE request to the SCC AS. 

7. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) - see example in table A.7.2-7 

The initial INVITE request is forwarded from intermediate IM CN subsystem entities in the home network to the 
SCC AS. The SCC AS acts as a routeing B2BUA as specified in 3GPP TS 24.229 [2]. 

Table A.7.2-7: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 

pcscf 1 .homel .net ;branch=z9hG4bK24 0f 34 . 1 , SIP/2 . 0/UDP 
[5555 : :aaa:bbb: ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 67 
Route: <sip : sccas .homel .net ; lr> 

Record- Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl .homel .net; lr> 

P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net>, <tel : +l-212-555-llll> 
P-Access-Network-Info: IEEE-802 . lib 
Privacy: none 
Require: replaces 
P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ;orig- 

ioi=type3ashomel .net> 
P- Charging- Function-Addresses : ccf = [5555 : :b99 : c88 :d77 : e66] ; ccf = [5555 : : a55 :b44 : c33 : d22] 

ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
From: <sip :userl_publicl@homel .net>; tag=171828 
To: <tel:+l-212-555-2222> 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Replaces: me03a0s09a2sdfgjkl491777; to-tag=774321; f rom-tag=64727891 
Contact : <sip :userl_publicl@homel .net ;gr=hdg7777ad7af lzig8sf 7> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp; application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 



8. Remote leg update 

The SCC AS based on the content of the Replaces header correlates the initial SIP INVITE request to the 
existing local and remote call legs of the existing concatenated end to end session between the UE-1 and UE-2. 
The SCC AS updates the remote call leg by sending a SIP re-INVITE request to the UE-2 containing the new 
SDP offer that it has received from the UE-1. 

9. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.7.2-9 
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The UE-2 is informed of the change in access leg by the SCC AS sending a SIP re-INVITE request to the S- 
CSCF. 

The SCC AS modifies the message in accordance with routeing B2BUA functionaHty, e.g. mapping of From, 
To, Cseq and Call-ID headers from one side of the B2BUA to the other. The SIP re-INVITE request contains the 
SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP INVITE request from the 

UE-l(Step5). 

Table A.7.2-9: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE <sip: [5555: :eee:fff :aaa:bbb] :8805 SIP/2.0 

Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 

Max- Forwards : 67 

Route: <scscf 1 .homel .net ; Ir >, <sip : scscf 2 .home2 .net ; lr>, <sip :pcscf 2 . visited2 .net ; lr> 

P-Asserted-Identity : "John Doe" <sip :userl_publicl®homel .net>, <tel : +l-212-555-llll> 

P-Access-Network-Info: IEEE-802 . lib 

Privacy: none 

P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" 

P-Charging-Function-Addresses : 

From: <sip :userl_publicl@homel .net>; tag=1717777 

To: <tel:+l-212-555-2222>, tag=4321 

Call -ID: dcl4bltlOb3teghmlk5 013333 

Cseq: 111 INVITE 

Supported: precondition, lOOrel 

Contact :<sip: [7777: :eee :ddd: ccc : aaa] > 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

0=2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c= IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a= curr:qos local sendrecv 

a= curr:qos remote none 

a= des:qos mandatory local sendrecv 

a= des:qos none remote sendrecv 

a= rtpmap:97 AMR 

a= fmtp:97 mode-set=0 , 2 , 5, 7; mode-change-period=2 

a= rtpmap:96 telephone-event 

a= maxptime:20 



Editor's Note: The SDP might need further revision. 

Route: The SIP re-INVITE request contains the saved list of Route headers that the SCC AS has saved for the 
remote leg of the call. 

10. SIP re-INVITE request (intermediate IM CN subsystem entities to intermediate IM CN subsystem 
entities) - see example in table A.7.2-10 

In the originating network, the intermediate IM CN subsystem entities forward the SIP re-INVITE request to the 
intermediate IM CN subsystem entities in the terminating network. 



ETSI 



3GPP TS 24.237 version 8.0.0 Release 8 51 ETSI TS 1 24 237 V8.0.0 (2009-01 ) 

Table A.7.2-10: SIP re-INVITE request (intermediate IM CN subsystem entities to intermediate IM CN 

subsystem entities) 



INVITE <sip: [5555 : :eee:fff :aaa:bbb] :8805 SIP/2.0 

via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP sccas.homel.net; 

branch=z9hG4bK332b33.3; 
Max- Forwards : 66 

Route : <sip:scscf2 .home2 .net; lr>, <sip :pcscf 2 . visited2 .net; lr> 

P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net>, <tel : +l-212-555-llll> 
Privacy: none 

From: <sip : userl_publicl®homel . net> ; tag=1717777 
To: <tel:+l-212-555-2222>, tag=4321 
Call-ID: dcl4bltl0b3teghmlk5013333 
Cseq: 111 INVITE 
Supported: precondition, lOOrel 
Contact : <sip : [7777 : : eee : ddd : ccc : aaa] > 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

0=2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s = - 

c= IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a= curr:qos local sendrecv 

a= curr:qos remote none 

a= des:qos mandatory local sendrecv 

a= des:qos none remote sendrecv 

a= rtpmap:97 AMR 

a= fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a= rtpmap:96 telephone -event 

a= maxptime: 20 



Editor's Note: The SDP might need further revision. 

11. SIP re-INVITE request (intermediate IM CN subsystem entities to UE-2) 

In the terminating network, the SIP re-INVITE request is forwarded towards the UE-2 by the intermediate IM 
CN subsystem entities. 

12. Media paths between UE-1 and UE-2 

The UE-2 receives the SIP re-INVITE request containing the SDP offer that indicates that the UE-1 is ready to 
receive the same media on a different contact address. Since the UE-2 has resources already available, it starts to 
send the media to the UE-l's contact address specified in the SDP offer immediately. 

The UE-1 will be receiving the RTP packets over new IP-C/Uvf. However, the UE-1 can receive some out-of- 
sequence RTP packets over the old IP -CAN. The RTP packets are delivered to the codec in sequence. Once the 
UE-1 determine that no media will be received over the old IP-C/VN (e.g. by examining the sequence numbers in 
the RTP headers), it can relinquish the resources that it has been using for incoming media on the old IP -CAN. 

The UE-1 sends the media to the UE-2 over the old IP-CAN. 

Resources used for signalling on the old IP -CAN are not released. 

13. SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE-2 has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

14. SIP 200 (OK) response (intermediate IM CN subsystem entities to intermediate IM CN subsystem entities) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the 
SIP re-INVITE request to the intermediate IM CN subsystem entities in the originating network. 
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15. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities in the originating network forward SIP the 200 (OK) response to the 
SIP re-INVITE request to the SCC AS. 

16. SIP ACK request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS acting as a B2BUA acknowledges the receipt of the SIP 200 (OK) response to the SIP re-INVITE 
request by forwards a SIP ACK request to the intermediate IM CN subsystem entities. 

17. SIP ACK request (intermediate IM CN subsystem entities to intermediate IM CN subsystem entities) 

In the originating network, the intermediate IM CN subsystem entities forward the SIP ACK request to the 
intermediate IM CN subsystem entities in the terminating network. 

18. SIP ACK request (intermediate IM CN subsystem entities to UE-2) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP ACK request to the UE- 

2. 

19. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS forwards the SIP 200 (OK) response to the initial SIP INVITE request to the intermediate IM CN 
subsystem entities, using the content of the Via header that was received in the initial INVITE request (step 5). 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID headers from one side of the B2BUA to the other. The SIP 200 (OK) response to the initial 
SIP INVITE request contains the SDP answer that is identical to the SDP answer that the SCC AS has received 
in the SIP 200 (OK) response to SIP re-INVITE request from the UE-2 (Step 13). 

20. SIP 200 (OK) response (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the UE-1. 

21. Media paths between UE-1 and UE-2 

The UE-1 receives the SIP 200 (OK) response containing the SDP answer that indicates that the UE-2 is ready to 
receive media. Since the UE-1 has already resources available, it starts to send media over new IP -CAN to the 
UE-2's contact address specified in the SDP answer immediately. 

The UE-1 may relinquish the resources that it has been using for outgoing media on the old IP-CAN. 

Resources used for signalling on the old IP -CAN are not released. 

22. SIP ACK request (UE-1 to intermediate IM CN subsystem entities) 

The UE-1 completes the new call leg creation with a SIP ACK request sent to the intermediate IM CN subsystem 
entities. 

23. SIP ACK request (-intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the SCC AS. 

24. SIP BYE request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg- that was using the old IP-CAN, by sending a SIP BYE request to 
the UE-1. 

25. SIP BYE request (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the BYE request to the UE-1. 

26. SIP 200 (OK) response (UE-1 to intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN, the UE-1 sends a SIP 200 (OK) response over the old 
IP-CAN. Subsequently, the UE-1 relinquishes all resources pertaining to the old IP -CAN. 
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27. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SCC AS. 

A. 7. 3 PS-PS access transfer with partial media transfer 

The signalling flows shown in figure A.7.3-1 describes the PS-PS access transfer procedure when not all media of an 
ongoing communication session are transferred from the Source Access Leg to the Target Access Leg. No lower-level 
mechanism to support the session continuity is assumed or needed. 

In this example, UE-1 is on an active multimedia session with UE-2 via one IP-CAN. After connecting to an additional 
IP -CAN, obtaining an additional IP address, discovering a P-CSCF, and performing IMS registration, UE-1 reserves 
resources in the new IP-CAN prior to initiating the PS-PS access transfer procedure. When the PS-PS access transfer 
procedure is completed, UE-1 continues the multimedia session with UE-2 on both the old and the new IP-CANs. In 
this example, when attaching to the new IP-CAN, it is irrelevant whether the UE-1 uses the same P-CSCF or a new 
P-CSCF. 

NOTE 1: This scenario requires that UE-1 and the IMS network support simultaneous multiple registrations and 
requires that UE-1 supports dual mode operation. 
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Figure A.7.3-1 : Signalling flow for PS-PS session transfer with partial media transfer 

NOTE 2: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. UE-1 is on an active session with UE-2 

UE-1 is in an active session with UE-2. The call is anchored in the SCC AS. It is irrelevant which endpoint 
initiated the call. Each call leg is uniquely identified with a respective dialog identifier. The call leg over IP- 
CAN #1 is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To 
tag=77432r'. UE-1 and UE-2 exchange media over the IP -CAN #1, which is maintained while the UE-1 initiates 
the session transfer procedure. 

2. UE-1 connects to IP-CAN #2 
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UE-1 connects to the new IP-CAN and obtains an IP address that it will use for the signalling and media. 

3. UE-1 registers with intermediate IM CN subsystem entities over IP-CAN #2 

UE-1 registers with the S-CSCF over the IP -CAN #2 using the standard registration procedure. The P-CSCF in 
the signalling path of this registration may be distinct from the one used in the signalling path over IP-CAN #1. 

4. UE-1 acquires resources in IP-CAN #2 

UE-1 decides to perform partial media transfer to the IP-CAN #2. Based on UE-1 and IP -CAN #2 capabilities, 
the UE-1 decides to use the same codec that was used over the IP -CAN #1 for the media components to be 
transferred. UE-1 ensures that the resources (e.g. QoS) in IP -CAN #2 that will be needed for the signalling and 
transferred media are available, prior to sending the initial SIP INVITE request. 

5. SIP INVITE request (UE-1 to intermediate IM CN subsystem entities) - see example in table A.7.3-5 

UE-1 sends initial SIP INVITE request with a new SDP offer to UE-2 and indicates that the video component is 
to be transferred to IP -CAN #2. The initial SIP INVITE request specifies new contact address that will be used 
for the signalling and media over IP -CAN #2. Upon sending the initial SIP INVITE request, UE-1 is ready to 
receive the RTP packets over both IP -CAN #1 and IP -CAN #2. 

Table A.7.3-5: SIP INVITE request (UE-1 to intermediate IM CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : sip :pcscf 1 .homel .net : 75 31; Ir ; comp=sigcomp> , <sip :orig@scscf 1 .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: IEEE-802 . lib 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171828 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj4903 3 3 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Require: sec-agree; tdialog 

Target-Dialog: me03a0s09a2sdf gjkl491777 ; remote-tag=774321; local-tag=64727891 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; portl=7531 

Contact : <sip :userl_publicl@homel .net ;gr=hdg7777ad7af lzig8sf 7>;comp=sigcomp 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; application/3gpp-ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio RTP/AVP 97 96 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=rtpmap:96 telephone-event 

m=video 3400 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



Request-URI: the tel-URI of the destination, i.e. the UE-2. 

Require: the "tdialog" option tag indicate that the support for Target-Dialog header is required. 

Target-Dialog: specifies the existing call that will be transferred. 
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SDP: specifies the new IP address that the UE-1 has acquired in the new IP-CAN, and indicates that only the 
video component will be transferred and the resources in the new IP-CAN have been reserved. 

Contact: specifies the IP address that the UE-1 has acquired in the new IP -CAN, and it will use for this call. 

6. Evaluation of initial filter criteria 

Upon the evaluation of the initial filter criteria, as this is an originating initial SIP INVITE request for a 
registered user, the S-CSCF routes the initial SIP INVITE request to the SCC AS. 

7. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The initial SIP INVITE request is forwarded from intermediate IM CN subsystem entities in the home network 
to the SCC AS. The SCC AS acts as a routeing B2BUA as specified in 3GPP TS 24.229 [2]. 

8. Remote leg update 

Based on the content of the Target-Dialog header, the SCC AS correlates the SIP INVITE request for session 
transfer to the existing local and remote call legs of the existing concatenated end to end session between UE-1 
and UE-2. The SCC AS updates the remote call leg by sending a SIP re-INVITE request to the UE-2 containing 
the new SDP offer based on the partial media transfer request received from UE-1 and the negotiated SDP for 
the original session. 

9. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.7.3-9 

UE-2 is informed of the change in access leg by the SCC AS sending a re-INVITE request to the S-CSCF. 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID headers from one side of the B2BUA to the other. The SIP re-INVITE request contains the 
SDP offer that is based on original SDP offer and the SDP offer that the SCC AS received in the initial SIP 
INVITE request from the UE-1 (Step 7). 
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Table A.7.3-9: SIP re-INVITE request (SCC AS to Intermediate IM CN subsystem entitles) 



INVITE <sip: [5555 : :eee:fff :aaa:bbb] :8805 SIP/2. 0> 

Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 

Max- Forwards : 70 

Route: <scscf 1 .homel .net ; lr>, <sip : scscf 2 .home2 .net ; lr>, <sip :pcscf 2 . visited2 .net ; lr> 

P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net>, <tel : +l-212-555-llll> 

Privacy: none 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 

P-Charging-Function-Addresses : 

From: <sip:userl_publicl@homel .net>; tag=1717777 

To: <tel:+l-212-555-2222>, tag=4321 

Call -ID: dcl4bltl0b3teghmlk50 13333 

Cseq: 111 INVITE 

Supported: precondition, lOOrel 

Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid:hdg7777ad7af IzigSsf 7> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

0=2987933100 2987933101 IN IP6 5555 : : aaa : bbb : ccc : eee 

s = - 

t = 

m=audio 3456 RTP/AVP 97 96 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

b=AS:25 .4 

a= curr:qos local sendrecv 

a= curr:qos remote none 

a= des:qos mandatory local sendrecv 

a= des:qos none remote sendrecv 

a= rtpmap:97 AMR 

a= fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a= rtpmap:96 telephone-event 

a= maxptime:20 

m=video 3400 RTP/AVP 98 99 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



Route: The SIP re-INVITE request contains the saved list of Route headers that the SCC AS has saved for the 
remote leg of the call. 

SDP: specifies the new IP address and ports used for the media components. In this case, the audio component is 
still using the original address and port while the video component is using the new IP address and new port 
allocated. 

10. SIP re-INVITE request (intermediate IM CN subsystem entities to intermediate IM CN subsystem 
entities) 

In the originating network, the intermediate IM CN subsystem entities forward the SIP re-INVITE request to the 
intermediate IM CN subsystem entities in the terminating network. 

11. SIP re-INVITE request (intermediate IM CN subsystem entities to UE-2) 

In the terminating network, the SIP re-INVITE request is forwarded towards UE-2 by the intermediate IM CN 
subsystem entities. 

UE-2 receives the SIP re-INVITE request containing the SDP offer that indicates that UE-1 is ready to receive 
video media on a different contact address. Since UE-2 has resources already available, it starts to send the 
media to UE-l's contact address specified in the SDP offer immediately. 

UE-1 starts receiving the video RTP packets over IP-CAN #2. However, UE-1 may receive some out-of- 
sequence video RTP packets over IP -CAN #1. The video RTP packets are delivered to the codec in sequence. 
Once UE-1 determine that no video will be received over IP-CAN #1 (e.g. by examining the sequence numbers 
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in the RTP headers), it may rehnquish the resources that it has been using for incoming video media on IP-CAN 

#1. 

At the same time, UE-1 still sends both the audio and video media to UE-2 over IP -CAN #1. 

Resources used for signalling on IP -CAN #1 are not released. 

12. SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) - see example in table A.7.3-12 

Upon receiving the SIP re-INVITE request containing the SDP offer, since UE-2 has all resources available, it 
sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

Table A.7.3-12: SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2 . 0/UDP pcscf2 .visited2 .net : 5 088 ;comp=sigcomp;branch=z9hG4bK361k21 . 1, 

SIP/2 .0/UDP scscf2 .home2 .net ;branch=z9hG4bK764z87 . 1 , 

SIP/2 .0/UDP scscf 1. homel.net ;branch=z 9hG4bK3 3 2b2 3 .1, 

SIP/2 .0/UDP sccas.homel.net;branch=z9hG4bK332b33 .3 
Record- Route : <sip ipcscf 2 . visited2 .net : 50 8 8 ; lr;comp=sigcomp>, <sip:scscf2 .home2 .net; lr>, 

<sip:scscfl .homel .net ; lr> 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 

From: <sip : userl_publicl@homel . net> ; tag=1717777 
To: <tel:+l-212-555-2222>;tag=4 321 
Call -ID: dcl4bltl0b3teghmlk5 013333 
CSeq: 111 INVITE 
Supported: precondition, lOOrel 

Contact : <sip:[5555::eee:fff :aaa :bbb] : 8805;comp=sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933623 2987933S24 IN IPS 5555 : : eee : f f f : aaa :bbb 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=audio 6544 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 20 

m=video 10001 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



13. SIP 200 (OK) response (intermediate IM CN subsystem entities to intermediate IM CN subsystem 
entities) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the 
SIP re-INVITE request to the intermediate IM CN subsystem entities in the originating network. 

14. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities in the originating network forward the SIP 200 (OK) response to the 
SIP re-INVITE request to the SCC AS. 

15. SIP ACK request (SCC AS to intermediate IM CN subsystem entities) 
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The sec AS acting as a B2BUA acknowledges the receipt of the SIP 200 (OK) response to the SIP re-INVITE 
request by forwards a SIP ACK request to the intermediate IM CN subsystem entities. 

16. SIP ACK request (intermediate IM CN subsystem entities to intermediate IM CN subsystem entities) 

In the originating network, the intermediate IM CN subsystem entities forward the SIP ACK request to the 
intermediate IM CN subsystem entities in the terminating network. 

17. SIP ACK request (intermediate IM CN subsystem entities to UE-2) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP ACK request to UE-2. 

18. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) - see example in table A.7.3- 
18 

The SCC AS forwards the SIP 200 (OK) response to the initial SIP INVITE request to the intermediate IM CN 
subsystem entities, using the content of the Via header that was received in the initial SIP INVITE request (step 
5). 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID headers from one side of the B2BUA to the other. The SIP 200 (OK) response to the initial 
SIP INVITE request contains the SDP answer derived from the SDP answer that the SCC AS has received in the 
SIP 200 (OK) response to SIP re-INVITE request from UE-2 (Step 14). 

Table A.7.3-18: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , 

SIP/2 .0/UDP pcscf l.homel.net;branch=z9hG4bK24 0f34 .1, 

SIP/2 . O/UDP [5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Record- Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl .homel .net; lr> 
Privacy: none 

From: <sip :userl_publicl®homel .net>; tag=171828 
To: <tel: +1-212 -555 -2222 >;tag=8009 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Contact: <sip:7777: : eee : ddd : ccc : aaa> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 5555 :: eee : fff : aaa : bbb 

s = - 

c=IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=audio RTP/AVP 97 96 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone-event 

m=video 10001 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



19. SIP 200 (OK) response (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to UE-1. 

UE-1 receives the SIP 200 (OK) response containing the SDP answer indicating that UE-2 is ready to receive 
media. Since UE-1 has already resources available, it starts to send video media over IP-C/VN #2 to UE-2's 
contact address specified in the SDP answer immediately. 
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The UE-1 may relinquish the resources that it has been using for outgoing video media on IP-CAN #1. 
Resources used for signalHng and audio media on IP-CAN #1 are not released. 

20. SIP ACK request (UE-1 to intermediate IM CN subsystem entities) 

UE-1 completes the new call leg creation with a SIP ACK request sent to the intermediate IM CN subsystem 
entities. 

21. SIP ACK request ( intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the SCC AS. 

22. SIP re-INVITE request (UE-1 to intermediate IM CN subsystem entities) - see example in table A.7.3-22 

UE-1 updates the old call leg on IP -CAN #1 by sending a SIP re-INVITE request to the intermediate IM CN 
subsystem entities. 

Table A.7.3-22: SIP re-INVITE request (UE-1 to intermediate IM CN subsystem entities) 



INVITE sip:7777: :eee:ddd:ccc:aaa SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : eee] : 2468 ;comp=sigcomp;branch=z9hG4bKashdnsl 

Max-Forwards: 70 

Route : sip :pcscf 1 .homel .net : 8 76 5 ; lr;comp=sigcomp>, <sip :orig@scscf 1 .homel .net ; lr> 

P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=123456ABCDE22 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=64727891 

To: <tel:+l-212-555-2222>; tag=774321 

Call -ID: me03a0s09a2sdfgjkl4 91777 

Cseq: 101 INVITE 

Supported: lOOrel; precondition; tdialog 

Require: sec -agree, - 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=12345678 ; portl=2468 

Contact : <sip :userl_publicl@homel .net ;gr=hdg7777ad7af lzig8sf 7>;comp=sigcomp 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; application/3gpp-ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933000 2987933001 IN IP6 5555 :: aaa :bbb : ccc : eee 

s = - 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t=0 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

m=video RTP/AVP 98 99 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



23. SIP re-INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to the SCC AS. 

24. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) - see example in table A.7.3- 
24 

The SCC AS updates the old call leg based on the SIP re-INVITE request and sends the SIP 200 (OK) response 
to the SIP re-INVITE request to the intermediate IM CN subsystem entities, using the content of the Via header 
that was received in the SIP re-INVITE request (step 23). The SIP 200 (OK) response to the SIP re-INVITE 
request contains the SDP answer derived from the SDP answer that the SCC AS previously received from UE-2 
(Step 14). 
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Table A.7.3-24: SIP 200 (OK) response (SCC AS to intermediate IIUI CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK345b32 .2, 

SIP/2 . 0/UDP pcscf 1 .homel .net ;branch=z9hG4bK5 6 8f 3 5 . 1 , 

SIP/2 . 0/UDP [5555 : : aaa : bbb : ccc : eee] : 2468 ; comp=sigcomp;branch=z9hG4bKashdnsl 
Record- Route : <sip:scscfl .homel .net ; lr>, <sip : pcscf 1 .homel .net; lr> 
Privacy: none 

From: <sip :userl_publicl®homel .net>; tag=64727891 
To: <tel:+l-212-555-2222>;tag=774 321 
Call -ID: me0 3a0s0 9a2sdfgjkl4 91777 
Cseq: 101 INVITE 

Supported: 10 Orel; precondition 
Contact: <sip:7777: : eee : ddd : CCC : aaa> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933800 2987933801 IN IP6 5555 :: eee : fff : aaa : bbb 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=audio 6544 RTP/AVP 97 96 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode- change -period=2 

a=rtpmap:96 telephone -event 

m=video RTP/AVP 98 99 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



25. SIP 200 (OK) response (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to UE-1. 

26. SIP ACK request (UE-1 to intermediate IM CN subsystem entities) 

UE-1 completes the old call leg update with a SIP ACK request sent to the intermediate IM CN subsystem 
entities. 

27. SIP ACK request ( intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the SCC AS. 

A.8 Signalling flows for PS-PS session continuity in 
conjunction with PS-CS session continuity 

A.8.1 Introduction 

A.8.2 PS - PS in conjunction with PS - CS Access Transfer: PS to 
CS 

In this example, SC UE A has an ongoing multimedia session with remote UE B over IP-CAN#1 before access transfer. 
When SC UE connects to a new IP-CAN#2, it decides to transfer the multimedia session over the new IP-CAN#2 and 
the CS bearer respectively. 
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Figure A.8.2-1 : Signalling flow for PS - PS in conjunction with PS - CS Access Transfer: PS to CS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

2. SC UE A has an ongoing multimedia session with remote UE B 

The call has been anchored at the SCC AS which is in the HPLMN of originating SC UE A. The call leg over 
old IP-CAN is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To 
tag=77432r'. The UE A and UE B exchange media over the old IP-CAN, which is maintained while the SC UE 
A initiates the handover procedure. 

Table A.8.2-1 shows an example of the SDP offer from SC UE A to remote UE B. 

NOTE 2: To later show how the media is transferred to the new IP -CAN and CS bearer, only the SDP offer is 
shown in the Table A.8.2-1. 

Table A.8.2-1 : SIP INVITE request (SC UE A to intermediate IM CN subsystem entities) 



INVITE tel:+l-237-555-2222 SIP/2.0 

Via: 

Max- Forwards : 

Route : 

P-Asserted- Identity : 

P-Charging-Vector : 

P-Access-Network-Info : 

Privacy: 

From: 

To: 

Call-ID: 

Cseq: 

Supported: 

Require : 

Proxy-Require : 

Security-Verify: 

Contact : 

Allow: 

Accept : 

Content-Type : 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = 

c=IN IP6 5555 : :aaa:bbb:ccc :ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 

m=message 7654 TCP/MSRP 98 

a=accept-types : text/plain 



2. SC UE A connects to a new IP-CAN#2: 

The SC UE A decides to transfer the multimedia session over the new IP-CAN and CS bearer respectively. The 
UE A obtains an IP address that it will use for the signalling and media. It registers with the S-CSCF over the 
new IP -CAN using multiple registrations procedure. Depending on the UE A configuration, the discovery of the 
P-CSCF in the new IP -CAN may be needed. Based on the UE A and new IP-CAN capabilities, the UE A decides 
to use the same codec that was used over the old IP-CAN. The UE A reserves resources (e.g. QoS) in the new 
IP-CAN that will be needed for the signalling and transferred media, prior to sending the initial SIP INVITE 
request. 

3. SIP INVITE request (SC UE A to intermediate IM CN subsystem entities)- see example in table A.8.2-3 
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The SC UE A sends an initial SIP INVITE request with a STI and a new SDP offer to the UE B that indicates 
that the new call replaces the existing call. The initial SIP INVITE request specifies new contact address that will 
be used for the signalling and non-realtime media over the new IP-CAN. Upon sending the initial SIP INVITE 
request, the UE A is ready to receive the RTP packets either over the new IP-CAN or the old IP -CAN. The RTP 
packets may arrive over the new IP-CAN prior to the SC UE are receiving the SIP 200 (OK) response for the 
initial SIP INVITE request. 

Table A.8.2-3: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE tel:+l-237-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : f f f ] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : sip :pcscf 1 .homel .net : 75 31; Ir ; comp=sigcomp> , <sip:orig@scscf 1 .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: IEEE-802 . lib 

Privacy: none 

From: <sip :userl_publicl®homel .net>; tag=171828 

To: <tel:+l-237-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490237 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Require: sec -agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; portl=7531 

Contact : <sip :userl_publicl@homel .net ;gr=hdg7777ad7af lzig8sf 7>;comp=sigcomp 

Target -Dialog :me0 3a0s0 9a2sdfgjkl4 91777; to-tag=774 321; f rom-tag=64 72 78 91 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; application/3gpp-ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : fff 

s = 

t = 

m=audio RTP/AVP 97 96 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 

m=message 7654 TCP/MSRP 98 

c=IN IP6 5555: :aaa:bbb:ccc:fff 

a=accept-types : text/plain 



4. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC. 

6. Remote Leg Update 

The SCC AS identifies the session to be transferred using the STI. The SCC AS performs the Remote Leg 
update by sending the SIP re-INVITE request towards the Remote Leg. 

7. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities)- See example in table A.8.2-7 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID headers from one side of the B2BUA to the other. The SIP re-INVITE request contains the 
SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP INVITE request from the 
UE A (Step 3). 
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Table A.8.2-7: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE <sip: [5555 : :eee:fff :aaa:bbb] :8805 SIP/2.0 

Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 

Max- Forwards : S7 

Route: <scscf 1 .homel .net ; Ir >, <sip : scscf 2 .home2 .net ; lr>, <sip :pcscf 2 . visited2 .net ; lr> 

P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net>, <tel : +l-237-555-llll> 

P-Access-Network-Info: IEEE-802 . lib 

Privacy: none 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 

P-Charging-Function-Addresses : 

From: <sip :userl_publicl@homel .net>; tag=1717777 

To: <tel:+l-237-555-2222>, tag=4321 

Call -ID: dcl4bltl0b3teghmlk50132 3 7 

Cseq: 111 INVITE 

Supported: precondition, lOOrel 

Contact :<sip: [7777: :eee :ddd: ccc : aaa] > 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : fff 

s=t=0 

m=audio RTP/AVP 97 96c=IN IP6 5555 :: aaa : bbb : ccc : ddd 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 

m=message 7654 TCP/MSRP 98 

c=IN IP6 5555: : aaa :bbb:ccc:fff 

a=accept-types : text/plain 



8. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forwards the SIP re-INVITE request to remote UE B. 
9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate IM CN subsystem entities) 

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
11-12: SIP ACK request (SCC AS to UE B via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE B. 
13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 

17. Media paths between UE A and UE B 

The non-realtime media is using the new IP -CAN while the realtime media path is still over the old IP-CAN. 

18. SETUP message (SC UE A to Interworking entities) 

The SC UE sends the CS SETUP message with the STN as the called party number. 
NOTE 3: STN is a PSI DN used by the UE to request a session transfer towards the SCC AS. 

19. SIP INVITE request (Interworking entities to Intermediate IM CN subsystem entities) -see example in 
Table A.8.2-19 
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Table A.8.2-19: SIP INVITE request (interworking entities to intermediate IM CN subsystem entities) 



INVITE tel:+l-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl.homel.net; branch=z9hG4bKnashds7 

Max- Forwards : 70 

Route : <sip : icscf 1 . homel . net : 7531 ; Ir ; comp=sigcomp> 

P-Asserted-Identity: <tel: +l-237-555-llll> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

P-Access-Network-Info : 

Privacy: none 

From: <tel: +l-237-555-llll>; tag=171828 

To: <tel:+l-237-555-2222> 

Call -ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Require: sec -agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; port=7531 

Contact: <sip :mgcf 2 .home2 .net> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Accept: application/sdp, application/3gpp-ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t=0 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 



Request-URI: contains the IMRN, as obtained from CS networks signalling. 

SDP; The SDP contains preconfigured set of codecs supported by the MGW. 

Editor" s Note: Details pertaining to ICSI vlaues in the Contact header, P-Preferred-Service header, P-Asserted- 

Service header. Accept header and Accept-Contact header need to be included in the the SIP requests and 
SIP responses of this call flow. 

Editor"s Note: The value that the interworking entities include in the the P-Access-Network-Info header in this 
SIP INVITE needs to be documented in this example. 

20. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

21. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

22. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

23. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) -see example in table A.8.2- 

23 

The SCC AS acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards UE B via the 
intermediate IM CN subsystem entities. 
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Table A.8.2-23: SIP re-INVITE request (SCC AS to intermediate IIUI CN subsystem entities) 



INVITE <sip: [5555 : :eee:fff :aaa:bbb] :8805 SIP/2.0 

Via: SIP/2. 0/UDP sccasl .homel .net;branch=z9hG4bKnas34r5 

Max-Forwards: 67 

Route: <sip : scscfl .homel .net : lr> 

P-Asserted-Identity: <tel: +l-237-555-llll> 

P- Charging- Function-Addresses : ccf = [5555: :b99:c88:d7 7:eee] ; ccf = [5555 : :a55 :b44 :c3 3 :d22] 

ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig- 

ioi="type3homel .net" 
P-Access-Network-Info : 
Privacy: none 

From: <tel: +l-237-555-llll>; tag=171828 
To: <tel:+l-237-555-2222>; tag=26545 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Supported: lOOrel, precondition 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; port=7531 
Contact: <sip : sccasl .homel .net> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Accept: application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t=0 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 

m=message TCP/MSRP 98 

a=accept-types : text/plain 



Editor"s Note: The value of the P- Access-Net work-Info header that is sent in the SIP re-INVITE request towards 
the called party needs to be documented in this example. 

24. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 

25. SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE B has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

26. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP re-INVITE request to 
the SCC AS in the originating network. 

27-28. SIP ACK request (SCC AS to UE B via IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE B. 

29-30. SIP 200 (OK) response (SCC AS to interworking entities via IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response to the interworking entities. 
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31. ISUP CONNECT message (interworking entities to SC UE A) 

32. ISUP CONNECT Response message (SC UE A to interworking entities) 

33-34. SIP ACK request (interworking entities to SCC AS via IM CN subsystem entities) 

The interworking entities generate the SIP ACK request to the SIP 200 (OK) response, and forward it to the SCC 
AS. 

35-36: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the old IP -CAN, by sending a BYE request to the 
UEA. 

37-38. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the BYE request over the old IP -CAN, the SC UE A sends a SIP 200 (OK) response over the old 
IP-CAN to the SCC AS. Subsequendy, the SC UE A relinquishes all resources pertaining to the old IP -CAN. 

39. Media paths between SC UE A and UE B 

Finally, the non-realtime media path is over the new IP-CAN and the realtime media is using the CS bearer. 

A.8.3 PS - PS in conjunction with PS - CS Access Transfer: CS to 
PS 

In this example, SC UE A has an ongoing multimedia session with remote UE B over IP-CAN#1 and CS bearer before 
access transfer. When SC UE connects to a new IP-CAN#2, it decides to transfer all the multimedia session over the 
new IP-CAN#2. 
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1 . SC UE A is on an active multimedia session with UE B. Call is anchored at SCC AS. 



Figure A.8.3-1 : Signalling flow for PS - PS in conjunction with PS - CS Access Transfer: CS to PS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 
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1. SC UE A has an ongoing multimedia session with remote UE B 

The non realmedia path is over old IP-CAN#1 and the reahime media path is over the CS bearer. The call has 
been anchored at the SCC AS which is in the HPLMN of originating SC UE A. The call leg over old IP-CAN#1 
is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To tag=774321". The UE 
A and UE B exchange media over the old IP-CAN, which is maintained while the SC UE A initiates the 
handover procedure. 

2. SC UE A connects to a new IP-CAN#2 

The SC UE A decides to transfer the multimedia session over the new IP-CAN#2. The UE A obtains an IP 
address that it will use for the signalling and media. It registers with the S-CSCF over the new IP-CAN using 
multiple registrations procedure. Depending on the UE A configuration, the discovery of the P-CSCF in the new 
IP-CAN may be needed. Based on the UE A and new IP-CAN capabilities, the UE A decides to use the same 
codec that was used over the old IP-CAN. The UE A reserves resources (e.g. QoS) in the new IP-CAN that will 
be needed for the signalling and transferred media, prior to sending the initial SIP INVITE request. 

3. SIP INVITE request (SC UE A to intermediate IM CN subsystem entities)- see example in table A.8.3-3 

Upon sending the initial SIP INVITE request, the UE A is ready to receive the RTP packets either over the new 
IP-CAN or the old IP -CAN. The RTP packets may arrive over the new IP-CAN prior to the SC UE are receiving 
the SIP 200 (OK) response for the initial SIP INVITE request. 

Table A.8.3-3: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE tel:+l-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc : f f f ] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 70 

Route : sip ipcscf 1 .homel .net : 7531; lr;comp=sigcomp>, <sip lorigOscscf 1 .homel .net; lr> 
P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Access-Network-Info: IEEE-802 . lib 
Privacy: none 

From: <sip :userl_publicl®homel .net>; tag=171828 
To: <tel:+l-237-555-2222> 
Call -ID: Cb03a0s09a2sdfglkj 490237 
Cseq: 127 INVITE 

Supported: lOOrel; precondition, gruu, 199 
Require: sec-agree, replaces 
Proxy-Require: sec-agree 

Accept -Contact : * ; +g. 3gpp . icsi-ref="urn%3Aurn-xxx%3gpp- service . ims . icsi .mmtel" 
P- Preferred- Service : urn:urn-xxx: 3gpp- service . ims .icsi .mmtel 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; portl=7531 
Contact : <sip :userl_publicl@homel .net ;gr= urn:uuid: f 81d4fae-7dec-lld0-a765- 
00a0c91e6bf 6 ; comp=sigcomp>; +g. 3gpp. icsi-ref="urn%3Aurn-xxx%3gpp- service . ims .icsi .mmtel" 
Replaces: me03aOs09a2sdfgjkl491777; to-tag=774321; f rom-tag=S4727891 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp; application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : f f f 

s = 

c = IN IP6 5555 : :aaa:bbb:ccc:fff 

t = 

m=audio 3456 RTP/AVP 97 96a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 20 

m=message 7654 TCP/MSRP 98 

a=accept-types : text/plain 



Request-URI: Contains the static STI. 
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4. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC. 

6. Remote Leg Update 

The SCC AS identifies the session to be transferred using the STI. The SCC AS performs the Remote Leg 
update by sending the SIP re-INVITE request towards the Remote Leg. 

7. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities)- See example in table A.8.3-7 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID headers from one side of the B2BUA to the other. The SIP re-INVITE request contains the 
SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP INVITE request from the 
UE A (Step 3). 

Table A.8.2-7: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE sip:user2_publicl®home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 SIP/2 . 

Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 

Max-Forwards: 67 

Route: <scscf 1 .homel .net ; Ir >, <sip : scscf 2 .home2 .net ; lr>, <sip :pcscf 2 . visited2 .net ; lr> 

P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net>, <tel : +l-237-555-llll> 

P-Access-Network-Info: IEEE-802 . lib 

Privacy: none 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023 551024" 

P-Charging-Function-Addresses : 

From: <sip :userl_publicl@homel . net> ; tag=569812 

To: <tel:+l-237-555-2222>, tag=4321 

Call -ID: dcl4bltl0b3teghmlk5 0132 3 7 

Cseq: 111 INVITE 

Contact : 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : f f f 

s = 

c = IN IP6 5555 : :aaa:bbb:ccc:fff 

t = 

m=audio 3456 RTP/AVPF 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 

m=message 7654 TCP/MSRP 98 

a=accept-types : text/plain 



8. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forwards the SIP re-INVITE request to remote UE B. 
9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate IM CN subsystem entities) 

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
11-12: SIP ACK request (SCC AS to UE B via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE B. 
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13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate EM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 

17. Media paths between UE A and UE B 

The multimedia is using the new IP-CAN. Resources used for signalling on the old IP-CAN#1 and CS bearer are 
not released. 

18-19. SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg- that was using the old IP-CAN#1, by sending a SIP BYE request 
towards the SC UE A. 

20-21. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN#1, the SC UE A sends a SIP 200 (OK) response over 
the old IP-CAN. Subsequently, the UE-1 relinquishes all resources pertaining to the old IP-CAN. 

22-23. SIP BYE request (SCC AS to interworking entities via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the CS bearer, by sending a BYE request. 
24-25. ISUP Message 

Upon receiving the DISCONNECT request, the SC UE A relinquishes all resources pertaining to the CS bearer. 
26-27. SIP 200 (OK) response (Interworking entities to SCC AS via intermediate IM CN subsystem entities) 
28. Media paths between UE A and UE B 

The multimedia session is using the new IP-CAN#2. 

A.9 Signalling flows for media adding/deleting 

Editor's note: This subsclause will contain signalling flows related to media adding/deleting. 

A.9.1 Introduction 

A.9. 2 Remote End Initiation case - Removing media from split CS 
and PS sessions 

As a precondition the SC UE A has a CS call and IMS multimedia session with the remote end after session transfer in a 
manner that more than one session are presented to UE B as one IMS session by the SCC AS. 
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SC UE A is on an active multimedia session with UE B. Call is anchored at SCC AS. 
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Figure A.9.2-1 : Remote End Initiation case - Removing media from split CS and PS sessions 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 
1. SC UE A has an ongoing multimedia session with remote UE B 

The call has been anchored at the SCC AS which is in the HPLMN of originating SC UE A. 
Table A.9.2-1 shows an example of the SDP offer from SC UE A to remote UE B. 
NOTE 2: To show how the media is removed, only the SDP offer is shown in this example. 
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Table A.9.2-1 : SIP INVITE request (SC UE A to intermediate IM CN subsystem entities) 



INVITE tel:+l-237-555-2222 SIP/2.0 

Via: 

Max- Forwards : 

Route : 

P- Asserted- Identity: 

P-Charging-Vector : 

P-Access-Network-Info : 

Privacy: 

From: 

To: 

Call-ID: 

Cseq: 

Supported: 

Require : 

Proxy-Require : 

Security- Verify: 

Contact : 

Allow: 

Accept : 

Content-Type : 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=message 7654 TCP/MSRP 98 

a=accept-types : text/plain 



2. SIP re-INVITE request (UE B to intermediate IM CN subsystem entities)- See example in table A.9.2.-2 

The remote UE B decides to remove the non-realtime media from the multimedia session. It uses standard IMS 
procedures to remove one or more PS media from the session. 
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Table A.9.2-2: SIP re-INVITE request (UE B to intermediate IM CN subsystem entities) 



INVITE <sip: [5555: :aaa:bbb:ccc:ddd] :8805 SIP/2.0 

Via: SIP/2. 0/UDP sccasl .homel .net;branch=z9hG4bKnas34r5 

Max-Forwards: S7 

Route: <sip : scscfl .homel .net : lr> 

P-Asserted-Identity: <tel: +l-237-555-2222> 

P- Charging- Function- Addresses : ccf=[5555::b9 9:c88:d7 7:e66]; ccf=[5555::a55 :b44 :c3 3 :d22] 

ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
P-Charging-Vector : icid-value="AyretyU0dm+SO2IrT5tAFrbHLso=023551024" ; orig- 

ioi="type3homel .net" 
P-Access-Network-Info : 
Privacy: none 

From: <tel: +1-237-555-2222; gr=hdg7777ad7af lzig8sf 7> ; tag=171828 
To: <tel:+l-237-555-llll> 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Supported: lOOrel, precondition 
Require: sec -agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; port=7531 
Contact: <sip : sccasl .homel .net> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Accept: application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = 

c = IN IP6 5555 : :aaa:bbb:ccc :ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 

m=message TCP/MSRP 98 

a=accept-types : text/plain 



3. SIP re-INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

4-5. SIP 200 (OK) response (SCC AS to UE B via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the remote 
UEB. 

6-7: SIP ACK request (UE B to SCC AS via Intermediate IM CN subsystem entities) 

The UE B generates the SIP ACK request to the SIP SIP 200 (OK) response and forwards it to the SCC AS. 

8-9: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the IP -CAN, by sending a SIP BYE request to the 
UEA. 

10-11. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the BYE request over the IP -CAN, the SC UE A sends a SIP 200 (OK) response over the IP- 
CAN to the SCC AS. Subsequendy, the SC UE A relinquishes all resources pertaining to the IP -CAN. 

12. Media paths between SC UE A and UE B 

Finally, the non-realtime media path over the IP-CAN is removed. 
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